Multiple Persistent Connection

daus95

Greetings everyone,

AFAIK, we can use a persistent connection to create shared connection per-process level. But it my case, I need to create multiple persistent connection.

I need to do this, because each visitor of my web site must have a single connection privately. This allows visitor to send single query one by one, and send commit command later. Of course, someone's query may not affect the other visitor.

Thank you.

[deleted]

pconnect does not let you do that.

It is not possible to open a persistant connection, close the script, start a new script, and use the same connection.

smarlowe

If you need to write an app with persistant connections per user, you're gonna have to learn java and write it for jdbc. Apache/php cannot guarantee holding a state like that for a certain connection (i.e. they'll hold a persistant connect, but don't guarantee it will be associate with a certain user.)

the other way is to build you data in session variables, then push it all in at once, but this could present some issues with consistency.

kparker

build you data in session variables, then push it all in at once,
but this could present some issues with consistency.

Scott, are you just thinking about what happens if someone else altered the data that the user saw the first time around, or something more dire?

If it's the first, then you can just include an image of original row contents--or, perhaps, only the columns which you possibly might update--along with the rest of the session data, and abandon the update if anything has changed in the meantime. (Yes, that's a lot of data, and a lot of checking, but is there any way else to safely do "optimistic" locking?)

kparker

Here's a great example of Optimistic row locking using a PostgreSQL trigger (sorry all you mysql folks...) One interesting twist is that the trigger also automatically timestamps the update, so instead of storing the entire row, the modifier only needs a copy of the previous timestamp. The author refers to using a hidden field for this, but for additional security it could be kept in a session variable.

http://www.brasileiro.net/postgres/cookbook/view-one-recipe.adp?recipe_id=965