Jonathan Whitehead escribi�:
>
> 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.
>
> ...
Hello again jonas-users
This is what InstantDB's support team had to say. I'd be grateful if
someone could tell me if solutions 1 or 2 are possible behaviours of
JOnAS:
-------- Original Message --------
>Asunto: Re: Bug query: deadlock using Jonas EJB server
>Fecha: Fri, 19 Nov 1999 12:15:06 -0000
>De: Instant Computer Solutions
>A: <[EMAIL PROTECTED]>
>
> Jonothan
>
> InstantDB is generally thread safe and normally spots deadlock situations.
> It generally assumes however that individual connections take place on
> separate threads. There are three possible sources of the current problem.
>
> 1. Multiple connections could be opened on the same thread. If con 1 locks a
> table and doesn't free it (say by not closing the ResultSet) and con 2 tries
> to access the table, then con 2 will block. InstantDB doesn't implement
> timeouts, so the whole thread will block. Strictly speaking, this is not a
> deadlock since another thread could close con 1 and resolve the situation.
> InstantDB has no way of knowing.
>
> 2. If JOnAS relies on the garbage collector to close ResultSet objects then
> it may be assuming that it is safe to open another connection on the same
> thread, or even new statements on an existing connection. Earlier versions
> of InstantDB were quite sensitive to this and the garbage collector and the
> thread with the lock would get into a true deadlock situation. This was
> supposed to be fixed in 3.00, however it's possible that there are still
> situations where this could cause problems.
>
> 3. Something completely new.
>
> It may be worth running 1 and 2 above past the JOnAS to see if they think
> either of these behaviours is likely. If they can definitely rule out 1 then
> it's an InstantDB problem.
>
> Regards
>
> Instant Computer Solutions
--
Jonathan Whitehead
Sema Group sae
[EMAIL PROTECTED]
(34) 91 440 8800 ext 7576
-----------------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------------
