Re: [OJB-developers] problems with OJB

[Thomas M. <tho...@ho...>]

Hi Matthew

Matthew Baird wrote:
> I'm sending this specifically to you two guys because you are the most
> active developers for the core of OJB.
> 
> We have big problems with objects being updated and cache consistency.
> 
> If you load an object in one VM, serialize it to another VM, then update
> fields and send it back and call store(x), you will end up with objects
> referencing that object becoming stale.
> 
> ie
> 
> FOO references BAR
> 
> load BAR (VM1)
> serialize BAR to VM2 set some attributes
> serialize BAR back to VM1 for update
> load FOO, now the FOO refers to the old BAR, not the updated BAR.
> 

IMHO this is a general architectural problem, not necessarily OJB specific.

What exactly are you trying to do? Are your clients OJB-ODMG clients or 
are the J2EE clients working against SessionBean controllers (and the 
Session is working against OJB interanlly)?
Or something else?

The big question is: how to manage distributed transaction accross 
multiple VMs.

I have several ideas how to approach this scenario:
- Use OJB c/s more (with servlet or SessionBean session bean facade to 
the server)
- before reaching objects to another VM remove them from the local cache
- Use proxies for all references
- have some additional methods to interact with the cache to place 
updated objects into the cache
- Extend the OJB ODMG implementation to support long transactions:
   when the client sends its modified BAR object back to the server the 
server must lock it to the current ODMG transaction.
In the current implementation we are always recording the state of the 
object to be locked into the ObjectEnvelopes field map.
To support long transactions we should rather record the latest commited 
state of the object into the map.
This would be very easy to implement (the method 
setInitialModificationState must be modified slightly).


> I'm looking at what it will take to fix this now, but I wanted you two big
> brains to start thinking about it as well. This is a subtle bug (in some
> cases) that is hard to write test cases for. 

I am not sure if it is really a bug. A serialized copy of BAR *is not 
the same* as the original BAR. But this is because Java has no notion of 
Object Identity. EJB entity beans provide object identity via PrimaryKey 
objects.
OJB works with the Identity concept.

> I'm seeing it because we seem
> to be the major users of OJB in J2EE where it's location transparency. 

I recently had some similar requests. Until shortly most people used OJB 
in Fat-client or servlet apps.

> the
> JDO API built on top of the PB will never really be right until this works.
> Luckily this is all encapsulated inside the PB.
> 
> I'm trying to come up with a more unified view of how getting objects and
> updating objects from the PB might work. It might be a smart thing to expose
> "read" and "write" get operations on the PB. I'm not sure right now.
> 

I think we need some more in-depth analysis of the problem. Mabye we 
need a whitepaper "how to use OJB with EJB SessionBeans". Maybe we also 
need some changes to PB and/or ODMG implementation.

cheers,
Thomas


> thoughts?
> m
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
>