Hmmm, thinking about it. I should really call commit on temporary
connections before closing to be on the save side...
Oliver
Oliver Zeigermann wrote:
So, you implemented your own connection pool? Cool stuff... If it works
what should be the problem.
I just checked DBCP the default connection pool for Slide and it
actually seems connections do not get committed or rolled back before
they are returned to the pool. However, I understand that no new
transaction is started on a connection when there is no write request in
it, right?
Oliver
Andreas Probst wrote:
on 2 Aug 2004 at 17:30, Oliver Zeigermann wrote:
I think a vote would be good. Since with the RDBMS stores a read
request can lock the database it should probably happen in a
transaction. I'm still learning the intricacies of transactions,
though, so don't take my word on it :).
Not quite sure what you mean here. If the read request is not part
of a transaction the locks will only be there for the duration of
this single read statement, not for the duration of the whole
transaction. This is better, isn't is?
With implicit transactions there will be database transactions
started automatically. These will last until the Connection.close().
Actually one should avoid closing connections. With a connection
pool a connection will never be closed so the transaction will last
until a commit or rollback.
Not quite sure what your intention is here. Could you please clarify?
For our project I'm bound to a Slide head version of late November
2003, where there wasn't a database connection pool yet. I think now
there is one somehow.
Within a few minutes there were hundreds of connections opened and
closed. This works for MS SQL Server on a Windows Server machine.
However, on Windows XP the closed connections were not freed fast
enough. So I got NoFreeSocket or so inside the SQLException. With
Oracle opening and closing connections all the time would not work at
all, no matter which OS. (This is what our database expert says.)
That's why I implemented a database connection pool. A call to
getConnection() or getNewConnection() or so in AbstractDBMSStore or so
(I don't know the names by heart and now I'm on vacation ;) returns a
connection from the pool of connections. The connections are bound to
the current thread. Within a single thread the same connection is
returned. Within another thread another connection is returned. When
close() is called on the connection wrapper object, it is not really
closed but put back to the pool of connections.
With this pool I have a fixed number of connection during the whole
runtime of the server. In my tests I archived more than 1 million
documents in one run. So this works.
As there is always the same connection returned within the same
thread, all statements live within the transaction, which was started
in the WebDAV layer. Even if the stores are not enlisted in the
transaction, they really are, because they work on the same database
connection.
I hope this does not cause any problems. So far it works fine for the
plain WebDAV operations.
I hope this explains what I meant...
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
