RE: [OJB-developers] High Low Sequence

[Bischof, R. <rai...@ed...>]

Jakob,

you got me. I was so sure that there is no reference to the Sequence
instances in the SeqMgr that I did not even have a look at it ;-(

Anyway: 
For those curios: I am using Sun JDK 1.3.1_01 on linux and Tomcat 3.3 in
default configuration without any tuning, OJB is running in single VM mode
and OJB is the only one that has access to the DB. Therefore I always have
increasing IDs, but sometimes the sequence of IDs has holes, e.g.
1,2,6,11,12,...

I can't explain it. Since the SeqMgr always uses it's own Hashtable to look
up the Seq objects the cache settings do not affect - I had the first few
holes again today :-(
All PBs use the SeqMgrFactory and should get the same SeqMgr since the
SeqMgrFactory has a static reference to the SeqMgr. 

Only thing I can imagine right now is that the SeqMgrFactory class is GCed?!
That way new SeqMgr instances may be created.

Regarding race conditions: In case there are multiple PB instances in
different VMs race conditions may occur, also in case the table is directly
modified by another program. 
So the HighLowSeq should not be used in distributed environments or the
issue needs to be fixed somehow.


Any ideas?

rb


-----Original Message-----
From: Joa...@tp... [mailto:Joa...@tp...]
Sent: Donnerstag, 21. Marz 2002 12:10
To: obj...@li...
Subject: [OJB-developers] High Low Sequence



[snip HighLowSequence objects being GCed, resulting in strange ID
sequences]

this doesn't result in incorrect behaviour, but I agree that it wastes
key-space unnecessarily, which is A Bad Thing.

> So there is a need to tell PB to cache instances of HighLowSequence
> forever without giving the GC a chance to collect them.
>
[snip MetaObjectCache solution]
>
> A better solution would be to implement a Set in the HighLowSequence
> where all new instances are added so that these objects are not
> eligible for GC even if the cache reference is only a SoftReference.

hm ... such a Set exists. To be more precise, there is a Hashtable in
SequenceManagerHighLowImpl that holds all HighLowSequence objects that the
SequenceManager has ever used, so they can't be GCed. So I can't see how
this behaviour could possibly happen (of course I don't doubt that you saw
it, I just can't explain why), unless the SequenceManagerHighLowImpl itself
get GCed and re-created (or there are several instances of it).

Maybe you're working with the client/server model. 'Cause then there are
several singlevm PersistenceBrokers on the server and you get to use a new
one each time you issue an command (unless you use and transaction). And
since each of these PersistenceBrokers has its own SequenceManager this
could result in equally confusing id-sequences (or even more confusing
ones, like 1,6,11,2,16,7,3,12,...)

Another possible problem with the SequenceManagerHighLowImpl (and possibly
the DefaultImpl as well) is that if several PersistenceBroker acessed the
same DB there could be race conditions, so we'd need to lock the obj_hl_seq
table (or at least one row). The question is wether it is possible/good
style to use the ODMG API (which seems the only way to do locking in OJB)
within a core class. (I've never actually seen such a race condition and
haven't run any tests, but I once noticed it and there don't seem to be any
pre-cautions for this; please correct me if I'm wrong).

> Regards Rainer

regards
Joachim Sauer


_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers