Hi,
We started to use cursors with hold in our project. Connection pool, that we use, has multiple connections.
Cursors with hold are connection-specific in postgresql, so they are visible only in the connection, in which they've been created. Using connection pool means, that in next execute, connection without cursor might be used, thus failing to access it.
Simplest solution would be to always use single connection for operations concerning cursors with hold, but it has obvious performance implications.
We wonder if it is possible to tweak our code/ozo code to solve this issue without abandoning multiple-connection pool.
Mechanism I can think of right now would require:
- ozo::execute (creating cursor, providing connection pool to be used) get information back about which connection was eventually used.
- next ozo::execute (using cursor created before) use connection that was in previous step
What do you think about this solution? Any hints on implementing it?
Or can you think about other solution to this problem?
Hi,
We started to use cursors with hold in our project. Connection pool, that we use, has multiple connections.
Cursors with hold are connection-specific in postgresql, so they are visible only in the connection, in which they've been created. Using connection pool means, that in next execute, connection without cursor might be used, thus failing to access it.
Simplest solution would be to always use single connection for operations concerning cursors with hold, but it has obvious performance implications.
We wonder if it is possible to tweak our code/ozo code to solve this issue without abandoning multiple-connection pool.
Mechanism I can think of right now would require:
What do you think about this solution? Any hints on implementing it?
Or can you think about other solution to this problem?