db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Armin Waibel" <armin.wai...@code-au-lait.de>
Subject Re: deadlock in sequenceManagerHighLowImpl (reopen OJB125?)
Date Thu, 03 Apr 2003 13:41:29 GMT
Hi Klaasjan,

this sucks! ;-)
the Hi/Lo sequence manager seems an endless story.

First, if your database supports database based sequence
generation you could use SequenceManagerNextValImpl
or SequenceManagerSeqHiLoImpl as an alternative SM.

> Hi,
> We've encountered the following deadlock with current OJB versions
> (including current CVS):
> In the class SequenceManagerHighLowImpl.getSequence(PersistenceBroker
> brokerForSequence, FieldDescriptor field, String sequenceName)
> According to this comment:
> /*
> arminw:
> we use a new internBroker instance, because we run into problems
> when current internBroker was rollback, then we have new sequence
> in memory, but not in database and a concurrent thread will
> get the same sequence.
> Thus we use a new internBroker instance (with new connection) to
> avoid this problem.
> */
> But because of this creating a new broker will create a new connection
> for getting the sequence number. On a loaded site it's possible for
> connection pool to temporarily run out of connections.

yes, but to use the same connection is not an alternative. It's a

> In our case: A DListEntry is being filled by a
> PersistenceBroker.getCollectionByQuery() that does have a connection
> its own. The new DlistEntry does a call to the
> SequenceManagerHighLowImpl.getUniqueLong(FieldDescriptor) to get a
> unique ID.
> That method contains a synchronized(sequencesMap) part.
> In this synchronize block it calls getSequence, which creates a new
> internBroker.
> That new persistenceBroker will try to get a new connection from the
> pool. But if the pool is exhausted then it will block there.
> Then every other call to the sequenceManager (which already holds a
> connection) will block on the synchronize(sequenceMap)!
> This looks very much like the recently closed bug OJB125, but it's
> present in the current version,.

It's a little bit different, because we now do the max id lookup with
the given PB instance (not the second intern used) and only when
the sequence entry object was not found in database, this should solve
the described tx-isolation problems.

> Anyone got an idea how to fix this?

Think the only way is to write an additional Hi/Lo SM:
- holds the HighLowSequence object entries in a non static Map
- is transactional aware and remove all sequence entries on rollback
to be in sync with database.


> --
> Klaasjan Brand <klaasjan.brand@topicus.nl>
> Topicus B.V.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message