I've got a client thread which does the following (simplified):


utx =
(UserTransaction)initialContext.lookup("javax.transaction.UserTransaction");
home = (TestHome) initialContext.lookup(beanName);

while (!terminated)
{
    utx.begin();    
    myTest = home.findByPrimaryKey(pk);
    System.out.println(myTest.getData()); // getData() simply returns
one of the bean's fields
    utx.commit();

    sleep(1000);
}


This works fine when there's just one client thread, but when there are
2 threads, sooner or later (usually sooner) we reach a deadlock
situation where both threads are waiting for a table lock to be released
in the InstantDB database.

I've gleaned the following information from the InstantDB trace log, I
don't know if it helps. Normally we see a TCP connection (I presume this
maps to a single database connection) obtaining multiple locks on the
table using a single transaction id. 

RMI TCP Connection(3)-172.18.101.242 Trans 4271 locked table: test10
Lock count=1
RMI TCP Connection(3)-172.18.101.242 Trans 4271 locked table: test10
Lock count=2
RMI TCP Connection(3)-172.18.101.242 Trans 4271 locked table: test10
Lock count=3
RMI TCP Connection(3)-172.18.101.242 Trans 4271 freed  table: test10
Lock count=2
RMI TCP Connection(3)-172.18.101.242 Trans 4271 freed  table: test10
Lock count=1
RMI TCP Connection(3)-172.18.101.242 Trans 4271 freed  table: test10
Lock count=0

But when it goes wrong the connection has a lock using one transaction
id and then tries to lock it again with a different transaction id.

RMI TCP Connection(8)-172.18.101.242 Trans 4281 locked table: test10
Lock count=1
RMI TCP Connection(8)-172.18.101.242 Transaction: 4281 has 1 lock(s) on
table: test10. 4271 Waiting...
RMI TCP Connection(7)-172.18.101.242 Transaction: 4281 has 1 lock(s) on
table: test10. 4283 Waiting...


I�m using a CMP entity bean, and I've tried various transaction
attributes in the deployment descriptor, and I've tried removing the
begin() and commit() from the client code. None of this makes any
difference. 

I'm using JOnAS 1.4.1, InstantDB 3.0, JDK 1.2.2, Windows NT.

Is this likely to be a problem with my code, or a bug in JOnAS or
InstantDB? Is InstantDB generally robust with multiple clients?

-- 
Jonathan Whitehead
Sema Group sae
[EMAIL PROTECTED]
-----------------------------------------------------------------------------------------
Este mensaje es confidencial y ata�e exclusivamente a las personas a las que va 
dirigido.
Cualquier opinion en el contenida, es exclusiva de su autor y no representa
necesariamente la opinion de Sema Group.
Si usted no es el destinatario de este mensaje, considerese advertido que lo ha 
recibido
por error y que cualquier uso, difusion o copia estan terminantemente prohibidos.
Si ha recibido este mensaje por error, por favor comuniquelo a Sema Group sae al
numero +34 91 4408800.

This email is confidential and intended solely for the use of the individual to whom 
it is addressed.
Any views or opinions presented are solely those of the author and do not necessarily 
represent
those of Sema Group. 
If you are not the intended recipient, be advised that you have received this email in 
error
and that any use, dissemination, forwarding, printing, or copying of this email is 
strictly prohibited.
If you have received this email in error please notify it to Sema Group sae by 
telephone on number
+34 91 4408800.
-----------------------------------------------------------------------------------------

Reply via email to