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]
