Roman,

> Right now implementation is not optimal, because it will use too many
> database connections. The only missing part from the server side for
> us seems to be decoupling transactions and connections. David Jencks
> was asking this long time ago.

With all deference to David, I have and will maintain that the solution
to this 'problem' lies outside the server.

I am not aware of any database server which does not relate
transaction(s) to a specific database connection -- how else could you
track/determine 'dead' transaction/connections?

The "decoupling transactions and connections" is something which can
(and IMHO should) be done within a threaded client-side
connection/transaction pool manager.

The abstraction of the transaction/connection can easily be done. The
solution lies in thinking of a client database object not as a
connection but as a transaction (naturally with an associated db
connection).

Thus, a client A could create a new database/transaction object, store
the object reference (ID #), perform some work, disconnect and the
reconnect (specifying the database object reference), and resume work
(commit/rollback).


Sean