You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Guido Beutler <gu...@hrs.de> on 2003/09/09 10:02:13 UTC
Deadlocks during OJB internal table access
Hello,
I'm using OJB 1.0 rc4 inside of jboss3.2.2rc3 and db2.
OJB is running into self generated deadlocks if I access ojb with
concurrent ejb clients when using SequenceManagerNextValImpl
As a workaround I use SequenceManagerInMemoryImpl but I think this won't
work with sequences.
If ojb could access his internal tables with read uncommitted this
should not
occur but it seems that OJB does not commit it's entries at the internal
tables, especially the sequence id's.
What can I do to get rid of the deadlocks?
best regards,
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Deadlocks during OJB internal table access
Posted by Guido Beutler <gu...@hrs.de>.
Hi Armin,
Armin Waibel wrote:
>Hi Guido,
>
>
>
>>Hello,
>>
>>I'm using OJB 1.0 rc4 inside of jboss3.2.2rc3 and db2.
>>OJB is running into self generated deadlocks if I access ojb with
>>concurrent ejb clients when using SequenceManagerNextValImpl
>>As a workaround I use SequenceManagerInMemoryImpl but I think this
>>
>>
>won't
>
>
>>work with sequences.
>>If ojb could access his internal tables with read uncommitted this
>>should not
>>occur but it seems that OJB does not commit it's entries at the internal
>>
>>tables, especially the sequence id's.
>>
>>
>
>Running within a j2ee container OJB should not commit any
>tx/connections. Each from OJB obtained DataSource was automatically
>enlisted in the running tx (thus it's not allowed to commit).
>Further I think it's not allowed to change
>transactionIsolation of DataSources (but maybe I'm wrong).
>
>
I think it won't be a good idea to change the isolation state of the
data source (even if it may be possible).
>
>
>>What can I do to get rid of the deadlocks?
>>
>>
>>
>Good question ;-)
>Can you discribe the deadlock more detailed?
>When does it occur, when create new sequence name
>(OJB can create missing sequence names by itself) or
>when lookup next sequence key?
>
Yes, at the lookup of the next sequence key at the same transaction.
If I have to generate only one new sequence id per transaction
everything works fine.
I already thought about a RequiresNew attribute (see my other mail
"OJB getting wrong transactin context or RequiresNew attribute (JBoss)
seems not to start new transaction"
at the list) and wrap all ojb stuff to own new transactions. The idea
was to get commits earlier than
at the end of the one large transaction. This would avoid to generate
several id's at one transaction
but this didn't work with jboss :-( .
>Can you write a test case (not ejb based) to reproduce
>your problem?
>
I think that the problem has to do with the transaction layer inside of
the ejb context so I don't think
that it is reproduceable outside of the ejb server.
I wasn't clear about the fact that the commits of the internal ojb
tables are dependent on the
EJB transaction.
>There is a multithreaded test case in CVS called 'SMMultithreadedTest'.
>This test simulate concurrent clients. This test pass when I use
>SequenceManagerNextValImpl and sapDB.
>
But it is not a ejb test case isn't it?
Anyway I should check it.
best regards,
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Deadlocks during OJB internal table access
Posted by Armin Waibel <ar...@code-au-lait.de>.
Hi Guido,
> Hello,
>
> I'm using OJB 1.0 rc4 inside of jboss3.2.2rc3 and db2.
> OJB is running into self generated deadlocks if I access ojb with
> concurrent ejb clients when using SequenceManagerNextValImpl
> As a workaround I use SequenceManagerInMemoryImpl but I think this
won't
> work with sequences.
> If ojb could access his internal tables with read uncommitted this
> should not
> occur but it seems that OJB does not commit it's entries at the
internal
> tables, especially the sequence id's.
Running within a j2ee container OJB should not commit any
tx/connections. Each from OJB obtained DataSource was automatically
enlisted in the running tx (thus it's not allowed to commit).
Further I think it's not allowed to change
transactionIsolation of DataSources (but maybe I'm wrong).
> What can I do to get rid of the deadlocks?
>
Good question ;-)
Can you discribe the deadlock more detailed?
When does it occur, when create new sequence name
(OJB can create missing sequence names by itself) or
when lookup next sequence key?
Can you write a test case (not ejb based) to reproduce
your problem?
There is a multithreaded test case in CVS called 'SMMultithreadedTest'.
This test simulate concurrent clients. This test pass when I use
SequenceManagerNextValImpl and sapDB.
regards,
Armin
> best regards,
>
> Guido
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org