db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raghuram Rajah <raghuram.ra...@s1.com>
Subject RE: OJB JDO
Date Wed, 21 May 2003 16:46:59 GMT
Hi Jeff/Thomas,

I had been talking a week or so back with Armin (see portions of the
transcript of the conversation below) about integrating OTM into PB and
having metadata to manage the specifics of implementations. I will write-up
something more specific this weekend so we can talk about it and look at
integrating this.

I also hear from Matt that Oleg is done with the implementations of the
strategies with OTM - thats awesome. Kudos to Oleg!


PS: I been notorious about design discussion, offline - will try and get
them more on the list going forward.

-----Original Message-----
From: "Armin Waibel" <armin.waibel@code-au-lait.de>
Reply-To: "Armin Waibel" <armin.waibel@code-au-lait.de>
To: "Raghuram Rajah" <rraghuram@hotmail.com>
Subject: Re: [OJB] PB caching
Date: Wed, 23 Apr 2003 14:10:28 +0200

----- Original Message -----
From: "Raghuram Rajah" <rraghuram@hotmail.com>
To: <armin@code-au-lait.de>
Sent: Wednesday, April 23, 2003 5:03 AM
Subject: Re: [OJB] PB caching

> Hi Armin,
> I think what you mention is exactly what OTM is doing. Since, OTM is
> going too far with its API, I suggest we integrate the OTM solution
into the
> 1.0 pb-caching directly instead of using the alternate OTM API.

This was my thought too.

> This would
> give PB tx-aware/isolation-aware caching.

OK, when we use PB-caching as starting point for OTM services
integration, what have I to do?
I would favour a step by step integration of the OTM services if
because it's easier to find bugs and OJB will always be stable (and it's
easier for me to understand ;-)).

The otm.cache.GlobalCache class use the locking service
to decide which ObjectCopyStrategy should be used.
The current broker.cache.ObjectCache methods don't have
a parameter 'lockHeld'. In that case always copies of objects
were used in the global cache - right?
To allow users to implement their own caching implementation
we should make LocalObjectCache(RequestContext) and
GlobalObjectCache pluggable. Should we add the additional
* public Object lookup (Identity oid, int lockHeld)
* public void cache (Identity oid, Object obj, int lockHeld)
to ObjectCache Interface, or should we use two Interfaces
one for LocalCaches, one for GlobalCaches?

Locally I moved the copy-package to ...broker.copy and add
methods to ClassDescriptor to support a per class copy strategy.

Could you tell me something more about how you will
integrate the OTM core stuff in the PB-api (I will try my best
to understand your comments, but be patient ;-))?


> It would also provide for support
> for swizzling, JCA-integration, etc. Potentially, we could introduce
> strategies to uniquing as well, at a later date.
> The current design of OTM is as follows,
>     ---> PB
>     --->(through cache) ObjectAdapter
>     ---> TransactionContext [the meat of OTM, managing
> aware of isolation levels and transactions]
> We could strip out just the core part of OTM - the TransactionContext
> provide that as specific strategies for pb-cache. If you are fine with
> I can look at quickly integrating this and possibly get rid of OTM as
> separate API layer.
> Thanks,
> Raghu.
> >From: "Armin Waibel" <armin@code-au-lait.de>
> >Reply-To: "Armin Waibel" <armin@code-au-lait.de>
> >To: <rraghuram@hotmail.com>
> >Subject: [OJB] PB caching
> >Date: Tue, 22 Apr 2003 21:18:13 +0200
> >MIME-Version: 1.0
> >Received: from mailout01.sul.t-online.com ([]) by
> >mc7-f25.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Tue,
22 Apr
> >2003 12:18:32 -0700
> >Received: from fwd03.sul.t-online.de by mailout01.sul.t-online.com
> >smtp id 1983Hi-0008TQ-0F; Tue, 22 Apr 2003 21:18:30 +0200
> >Received: from win (510007636964-0001@[]) by
> >fmrl03.sul.t-online.comwith smtp id 1983HU-0kQVxgC; Tue, 22 Apr 2003
> >21:18:16 +0200
> >X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP
> >Message-ID: <013701c30903$eb8ffd60$6479fea9@win>
> >X-Priority: 3
> >X-MSMail-Priority: Normal
> >X-Mailer: Microsoft Outlook Express 5.50.4522.1200
> >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
> >X-Sender: 510007636964-0001@t-dialin.net
> >Return-Path: armin@code-au-lait.de
> >X-OriginalArrivalTime: 22 Apr 2003 19:18:33.0273 (UTC)
> >FILETIME=[F7293290:01C30903]
> >
> >Hi Raghu,
> >
> >I'm currently working on the PB-cache stuff
> >and agonise over a two level cache solution,
> >similar to your concept in OTM.
> >I don't want re-build your OTM solution, but
> >I think we need a more sophisticated caching
> >solution for release 1.0, because e.g. the ObjectCacheDefaultImpl
> >does not work properly with concurrent threads.
> >And the ObjectCachePerBrokerImpl isn't really
> >performant.
> >
> >My intention was:
> >
> >PreObjectCache [optional: --wraps--> CacheFilter] --
> >--wraps--> 'an arbitrary' ObjectCache implementation
> >
> >A CacheFilter implementation allows the user to avoid caching of
> >specific objects (e.g specific classes or packages by using
> >custom attributes).
> >
> >The PreObjectCache is very similar to RequestContext
> >(thanks for your post on the user list). It's based on a per tx
> >manner. If a PB-tx was started the PreCache is enabled.
> >all cache(...) calls buffered by the PreCache, when the PB-tx
> >was commited all buffered objects were pushed to the 'real' cache
> >implementation (on abort all buffered objects were discarded).
> >
> >The problem is the lookup(...) method. When we in a PB-tx and
> >the we lookup an object from the 'real' ObjectCache we should use
> >a copy of this object. Maybe we should use a copy on every
> >lookup of the real cache (if real cache was a global cache
> >implementation),
> >because we don't now if the user does only read or a write operation
> >the used object.
> >
> >To copy the objects I want to use your very smart solution made in
> >the copy-package of the OTM. I want to add the copy-strategy
> >to the class-descriptor, thus every class could use their own
> >
> >Does this make sense? What do you think?
> >
> >regards,
> >Armin
> >
> >
> >
> >
> >
> >
> >

-----Original Message-----
From: Jeffrey Sheldon [mailto:jsheldon@datavantagecorp.com]
Sent: Friday, May 16, 2003 4:43 PM
To: OJB Developers List; thma@apache.org
Subject: RE: OJB JDO

I tend to agree with your comments about the otm being included in the PB,
this should make it easier to interface with both api's, but as you said, we
can cross that bridge when we come to it.

- Jeff

-----Original Message-----
From: Thomas Mahler [mailto:thma32@web.de]
Sent: Friday, May 16, 2003 4:18 PM
To: OJB Developers List
Subject: Re: OJB JDO

Hi agaian Jeffrey,

Jeffrey Sheldon wrote:
> Ok, sorry it has taken me so long to get back to you, but I have
> reviewed the existing proposal and it seems to be pretty solid.

We are not in hurry!
In the year that passed since I wrote the initial proposal. Several 
things have changed. I'd like to mention two of them here:
- I proposed to write a JDO prototype on top of the PB to learn more 
about refactoring between ODMG and JDO. We now have a working JDO 
prototype on top of PB. But as it is written as a plugin to the SUN 
JDORI it won't reveal much details on possible code synergies.

- In the meantime we have a lot of working code in the OTM layer. Most 
prominent the caching stuff.
There have been some discussions if it makes sense to merge OTM and PB 
to have all the cool caching features of OTM caches available in the PB.
So there be not that many things left for the OTM layer...
IMO we have to make up our minds if it's still valid to write ODMG and 
JDO on top of OTM. The last has shown that it's much easier to improve 
the ODMG layer by placing it directly on top of PB.

These are only my 2cents. You should feel free to proceed in any way you 
prefer. I think it's the best think to get things started now and to 
improve them later.

> Unless anyone has any objections, I will proceed as follows:
> 1.  Create stubbed implementations of PersistenceManager,
> StateManager, and PersistenceManagerFactory in that order. 2.  Begin
> coding methods to A.  Obtain a persistence manager B.  Get an object
> by its identity C.  modify fields in the object D.  commit the object
> back to the datastore. 3.  Write tests for the above methods/classes
> as appropriate.

+1. But even in this first simple steps we should already be compatible 
to the bytecode enhancement of the reference enhancer!

> Along the way I will attempt identify dependencies between
> methods/classes in the jdo implementation to create a roadmap for
> development.  

Good approach.

> Also, I will attempt to identify areas where
> functionality needs to be refactored out of existing OJB areas so
> that it may be re-used by the OJB JDO implementation.

I feel this is much better than having all these discussions in advance. 
lets' start the work now.

> All comments and suggestions are welcome.  Assuming there are no
> objections, I will start work this weekend, and will be able to have
> some code to submit shortly.



> Thanks,
> Jeff Sheldon
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For
> additional commands, e-mail: ojb-dev-help@db.apache.org

To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message