On Fri, 28 Mar 2003 12:40:58 -0000, you wrote:

>Deadlock most likely is not caused by a bug in the driver, but a bug
>in your tests. However it is hard to tell why, because I need test
>that reproduces the bug. Can you create one?

no. i can't because it's the first time i have a deadlock in absolute
since i started making tests and it's not reproducible because i don't
know the cause.
Have you looked at my yesterday's post? That errors are more frequent
than the deadlock one and maybe they can give some clue about the cause
of the problem.
However during normal debugging tests (so very low load on the
application) i have no problems. Problems occurs when i have more
clients that continuosly stress the application: normally i have about
40 or 50 clients that connect simultaneously and perform requests
continuosly to the application.

>> accept a tcp connection
>> log in the database the request made (insert a row)
>> insert a row in another table after some processing (not db
>> processing) update the inserted row after some processing (not db
>> processing) say goodbye close the tcp connection
>
>If you use concurrent transactions in this case, you can run into the
>deadlock.

i don't think so. i forget to mention that the inserted row is updated
by the same thread in the same connection and that other threads work on
different rows and connections (from the same pool). they never update a
row inserted by another thread.

>
>> yesterday i had errors making the "log" insert.
>> tonight i had errors making the update.
>> i forget to mention that i made query in autocommit mode.
>
>What transaction isolation do you use?

i do not specify a transaction isolation level.

here is how i create the connection pool:

fbwds = new org.firebirdsql.jdbc.FBWrappingDataSource();
fbwds.setDatabase(connUrl);
fbwds.setUserName(user);
fbwds.setPassword(password);
fbwds.setIdleTimeoutMinutes(idleTimeout);
fbwds.setBlockingTimeout(blockingTimeout);
fbwds.setLoginTimeout(loginTimeout);
fbwds.setPooling(true);
fbwds.setMinSize(minSize);
fbwds.setMaxSize(maxSize);
FBDriverLoaded = true;

fbwds is an object shared by all the threads that use the pool.

here's the code used to get a connection from the pool, i think there's
no problem changing the autocommit level of a pooled connection, by the
way autoCommit is alway set to true during this tests:

conn = fbwds.getConnection();
conn.setAutoCommit(autoCommit);

and here's how i release the connection when finished:

conn.close();

Maybe should i synchronize the access to the FBWrappingDataSource? Or
the getConnection method is already synchronized?

thanks
ciao
--
Seti@Home Java Applets
http://maruko.cjb.net/