Re: Deadlocks during OJB internal table access

[Guido Beutler]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]