AW: [OJB-developers] Single VM Object Cache Consistency?

[Mahler T. <tho...@it...>]

Hi John,

 
> I've worked through just about every technical question I 
> have on OJB's
> applicability to my current project.  The last nagging question I have
> is about object cache consistency.
> 
> I see that within a single VM that multiple PersistenceBrokers share a
> singleton object cache.

right.
 
<snip treading example>
> 
> In this scenario, the db transactions within each thread become
> intertwined in a way because each thread has no idea the other thread
> may have made additional changes to the object state within 
> the context
> of its own transaction.  It could easily end up committing unintended
> state changes.
> 

You are right. There is no protection of this kind on the PersistenceBroker 
level as it provides no Object level transaction management.
This is currently only possible if you were using the OJB-ODMG API that
provides
a full fledged Object level Transaction management.

http://objectbridge.sourceforge.net/system/lockmanager.html


> Also, this would seem to indicate that every class that could be
> persisted with OJB would need to be either immutable or 
> thread safe (if
> you are using OJB in this sort of context).
> 
> Is there some other common way folks get around this that I'm 
> completely
> missing (or something else OJB is doing behind the scenes)?

On the PB level there is not much going on behind the scenes...

> It really seems like in this sort of context that each PB should have
> its own object cache which is flushed after each transaction
> commit/rollback.  

The original intention of a cache was not primarily to boost performance 
but to maintain uniqueness of persistent Objects accross a VM.

But without tx isolation on the PB level this is dangerous as your
example shows.
Maybe we need a redesign of this aspect. There are similar thoughts in
the JDO spec. They only provide uniqueness of objects within one
transaction.

having transaction local caches would be the most simple solution and
simplify a lot of things (e.g. cache synchronization).

> Or create a more sophisticated object cache that you
> could mark some classes as immutable so that they could be 
> shared across
> transactions & threads this way.  Actually, it looks like the
> MetaObjectCacheImpl may be just what I'm looking for.
> 

No, the MOC is just a hierarchical cache that allow to use one 
dedicated cache per class.
There is currently nothing of your ideas implemented there.

cu,

Thomas

> Thoughts?
> 
> Thanks much,
>  - John Freeborg
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>