On 06/18/2009 02:42 AM, Pavel Golub wrote:
Now to implement customer's desire in PostgreSQL there are two ways:
1. Each script must be executed in the separate connection context
2. Each script must be executed inside critical section, in other
words current scipt must block others until COMMIT or ROLLBACK
I don't like both.
What don't you like about 1) ?
I don't know of any other databases that work this way. Using separate
connections and connection pooling seems to be "the way to go" here.
Personally, I found the "named transaction" concept a little skrewy unless:
1) SQL commands can be sent asynchronously as long as they are for
different named transactions, even while other transactions are still
running.
2) Each transaction runs in a different server-side thread.
If this is what you want, it sounds like you are just trying to
multiplex multiple queries and responses over the same TCP/IP
connection. For the added complexity on both the client and the server,
do you really think it is worth it?
If you just want a connection multiplexor that is backed by a connection
pool - I think that would be a lot easier to provide. :-)
Cheers,
mark
--
Mark Mielke<m...@mielke.cc>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
