Re: JDO && OJB
JDO Central ( http://www.jdocentral.com/ ) is a good JDO starting point. The best source for info on JDOQL is the spec, it is actually pretty clear, I think ( http://jcp.org/aboutJava/communityprocess/pr/jsr243/index2.html ). OJB's JDO implementation is more proof-of-concept than production-usable. A good open source JDO implementation is JPOX ( http://www.jpox.org/ ). Before long there should be an Apache JDO ( http://wiki.apache.org/jdo/ )project which can use OJB as the O/R Mapping backend. -Brian On Mar 19, 2005, at 7:09 PM, Markus Wolf wrote: Are there any advanced tutorials for JDOQL available? Or has someone some links to good resources about JDOQL? Regards Markus Wolf -- emedia-solutions wolf Wedeler Landstrasse 63 22559 Hamburg (040) 550 083 70 web: http://www.emedia-solutions-wolf.de mail: [EMAIL PROTECTED] pgp: http://wwwkeys.de.pgp.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Will a two-level cache solve this problem?
The Two Level Cache is part of the OJB 1.0.2 release, which should be released any day now. You can upgrade then and change your Cache declaration in your repository.xml file to specify that you want the TLCache. I am using it now (with a release build), and it solves this problem. This is a slight performance degregation, but not significant, and defintly worth it to ensure clean objects from the cache. -Andrew From: Ziv Yankowitz [mailto:[EMAIL PROTECTED] Sent: Sun 3/20/2005 2:51 AM To: OJB Users List Subject: RE: Will a two-level cache solve this problem? Hi All, we are new to the OJB and we have the same problem. we are using ojb 1.1 can someone please explain how can we implement the two-level cache? Thanks -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 5:16 PM To: OJB Users List Subject: Re: Will a two-level cache solve this problem? Clute, Andrew wrote: > Good news, I think. > > Just so I can understand, I want to clarify: The global cache will be > the same as the cache today, and will contain full graphs. The second level cache only contain "flat objects", but as second level cache you can declare all ObjectCache implementations. When OJB lookup an object from the TwoLevelCache the second level lookup the "flat objects" and materialize the full object graph. Here is the only performance drawback, to materialize the 1:n, m:n relations OJB have to query for the references id's. Maybe you could mix the used cache strategies. In the jdbc-connection-descriptor declare the TLCache and for read-only object (or less updated objects) declare the default cache in class-descriptor. > When an > object is retrieved, a copy of the object is returned to the client, and > that copy is placed into the second-level global cache? Right. So, any object > that is used from a retrieve mechanism is dereferenced from the objects > that are in the cache, and whatever the client does to them is not > affecting the cache? > That's the theory ;-) > If so, that is very cool! I don't really want to worry about a locking > strategy, because it seems to be overhead that we don't need -- using > optimistic locking works well enough for us. This seems like it gives me > the best of both worlds -- I don't have to worry about read locks, but I > also don't have to worry about mutating the global cache until my TX > commits. > > I would assume that the second-level cache doesn't commit to the global > cache until the Tx commits, right? Right, except for new materialized objects. These objects will be immediately pushed to the second level cache (flat copies). I introduce this to populate the cache, otherwise only changed objects will be put in the cache. > I would also assume that JTA based TX > won't make a difference? > Yep, should work in non- and managed environments. > All very cool stuff! > Wait and see ;-) > You mentioned that this will be included in the next release, but I > assume you mean 1.1, and not 1.0.2, right? No, it will be part of the upcomming 1.0.2 release (scheduled for Sunday). Armin > If it is meant for 1.1, is > there a release that is stable enough if all I care to do is add this > caching-strategy to a 1.0.X release featureset? > > Thanks for all the help! > > -Andrew > > > > > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 09, 2005 9:40 AM > To: OJB Users List > Subject: Re: Will a two-level cache solve this problem? > > Hi Andrew, > > > So, my question is will the introduction of a two-level cache isolate > >>clients of OJB from mutating the object that is in the real cache? > > > yep! > > > Are > > the objects that are in the local cache versus the global cache > > different references, or are they the same? > > > > They are different, the second level cache only deal with flat (no > references populated) copies of the persistent class objects. The used > CopyStrategy is pluggable. > > In OJB_1_0_RELEASE branch the first version of the two-level cache work > this way (will be included in next release). > > > > Is my only true option to go with an ODMG/OTM locking strategy to > > isloate my reads from writes? > > > > You could write an thin layer above the PB-api using the kernel locking > api in org.apache.ojb.broker.locking (OJB_1_0_RELEASE branch). > > regards, > Armin > > > Clute, Andrew wrote: > >>Hello all! >> >>I have a standard 3-tier webapp back with OJB in my business layer. We >>are using the PB API. We have a host of domain objects, that is passed >>up to the web tier and used for form manipulation. >> >>The standard pattern for us when editing an object is: >> >>1) Retrieve business object from PersistenceService >>2) Use object and integrate it to set form elements >>3) Place object into HttpSession for later >>4) On submit pass, take object out of HttpSession, and then populate >>date from form back
RE: Will a two-level cache solve this problem?
Hi,
we are new to ojb and use version 1.0.1.
we have the sample problem can someone please explain how to implement the two
level cache?
Thanks
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 09, 2005 6:11 PM
To: OJB Users List
Subject: Re: Will a two-level cache solve this problem?
Clute, Andrew wrote:
> I do have one more question, which I assume a lot of people will have:
> If I am reading this write, when using a TLCache, objects that are
> returned to a client that have 1:N or M:N relationships will have to had
> another query to get the FK's for those collections?
Right, because the "flat objects" don't know about the referenced
objects. The "flat object" is passed to method #materializeFullObject
private void materializeFullObject(Object target)
{
ClassDescriptor cld = broker.getClassDescriptor(target.getClass());
// don't force, let OJB use the user settings
final boolean forced = false;
broker.getReferenceBroker().retrieveReferences(target, cld, forced);
broker.getReferenceBroker().retrieveCollections(target, cld, forced);
}
> How does this work
> when using Proxies for collections?
>
In the same way, the "flat object" will be materialized with collection
proxies. In this case the TLCache don't query for the collection FK's,
because collection proxy objects will be used. The reference handling
always base on auto-XXX settings in the collection/reference-descriptor.
> I am only having to pay the hit of a single query to get all the FK's,
> and *not* having to pay for retrieving full objects (thus making Proxied
> collections worthless)?
Think I wasn't clear in my previous post or I don't understand your
question (or both ;-)), as said above the collection proxy stuff work as
before.
> I assume you need the FK's to accurately handle
> the copying between cache-levels.
when no collection proxy used, the FK's are needed to find the
referenced objects.
> Does this all sound accurate?
>
> Thanks again, this 1.0.2 is really shaping up to be more than a point
> release!
>
Maybe we should engage a advertising agency and call the release "OJB
2.0 Anaconda" ;-)
Armin
> -Andrew
>
>
>
> -Original Message-
> From: Armin Waibel [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 09, 2005 10:16 AM
> To: OJB Users List
> Subject: Re: Will a two-level cache solve this problem?
>
> Clute, Andrew wrote:
>
>>Good news, I think.
>>
>>Just so I can understand, I want to clarify: The global cache will be
>>the same as the cache today, and will contain full graphs.
>
>
> The second level cache only contain "flat objects", but as second level
> cache you can declare all ObjectCache implementations.
> When OJB lookup an object from the TwoLevelCache the second level lookup
> the "flat objects" and materialize the full object graph. Here is the
> only performance drawback, to materialize the 1:n, m:n relations OJB
> have to query for the references id's.
>
> Maybe you could mix the used cache strategies. In the
> jdbc-connection-descriptor declare the TLCache and for read-only object
> (or less updated objects) declare the default cache in class-descriptor.
>
>
>
>>When an
>>object is retrieved, a copy of the object is returned to the client,
>>and that copy is placed into the second-level global cache?
>
>
> Right.
>
>
> So, any object
>
>>that is used from a retrieve mechanism is dereferenced from the
>>objects that are in the cache, and whatever the client does to them is
>
>
>>not affecting the cache?
>>
>
>
> That's the theory ;-)
>
>
>
>>If so, that is very cool! I don't really want to worry about a locking
>
>
>>strategy, because it seems to be overhead that we don't need -- using
>>optimistic locking works well enough for us. This seems like it gives
>>me the best of both worlds -- I don't have to worry about read locks,
>>but I also don't have to worry about mutating the global cache until
>>my TX commits.
>>
>>I would assume that the second-level cache doesn't commit to the
>>global cache until the Tx commits, right?
>
>
> Right, except for new materialized objects. These objects will be
> immediately pushed to the second level cache (flat copies). I introduce
> this to populate the cache, otherwise only changed objects will be put
> in the cache.
>
>
>
>>I would also assume that JTA based TX
>>won't make a difference?
>>
>
>
> Yep, should work in non- and managed environments.
>
>
>
>>All very cool stuff!
>>
>
>
> Wait and see ;-)
>
>
>>You mentioned that this will be included in the next release, but I
>>assume you mean 1.1, and not 1.0.2, right?
>
>
> No, it will be part of the upcomming 1.0.2 release (scheduled for
> Sunday).
>
> Armin
>
>
>>If it is meant for 1.1, is
>>there a release that is stable enough if all I care to do is add this
>>caching-strategy to a 1.0.X release featureset?
>>
>>Thanks for all the help!
>>
>>-Andrew
>>
>>
>>
>>
>>
>>-Original
RE: Will a two-level cache solve this problem?
Hi All, we are new to the OJB and we have the same problem. we are using ojb 1.1 can someone please explain how can we implement the two-level cache? Thanks -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 5:16 PM To: OJB Users List Subject: Re: Will a two-level cache solve this problem? Clute, Andrew wrote: > Good news, I think. > > Just so I can understand, I want to clarify: The global cache will be > the same as the cache today, and will contain full graphs. The second level cache only contain "flat objects", but as second level cache you can declare all ObjectCache implementations. When OJB lookup an object from the TwoLevelCache the second level lookup the "flat objects" and materialize the full object graph. Here is the only performance drawback, to materialize the 1:n, m:n relations OJB have to query for the references id's. Maybe you could mix the used cache strategies. In the jdbc-connection-descriptor declare the TLCache and for read-only object (or less updated objects) declare the default cache in class-descriptor. > When an > object is retrieved, a copy of the object is returned to the client, and > that copy is placed into the second-level global cache? Right. So, any object > that is used from a retrieve mechanism is dereferenced from the objects > that are in the cache, and whatever the client does to them is not > affecting the cache? > That's the theory ;-) > If so, that is very cool! I don't really want to worry about a locking > strategy, because it seems to be overhead that we don't need -- using > optimistic locking works well enough for us. This seems like it gives me > the best of both worlds -- I don't have to worry about read locks, but I > also don't have to worry about mutating the global cache until my TX > commits. > > I would assume that the second-level cache doesn't commit to the global > cache until the Tx commits, right? Right, except for new materialized objects. These objects will be immediately pushed to the second level cache (flat copies). I introduce this to populate the cache, otherwise only changed objects will be put in the cache. > I would also assume that JTA based TX > won't make a difference? > Yep, should work in non- and managed environments. > All very cool stuff! > Wait and see ;-) > You mentioned that this will be included in the next release, but I > assume you mean 1.1, and not 1.0.2, right? No, it will be part of the upcomming 1.0.2 release (scheduled for Sunday). Armin > If it is meant for 1.1, is > there a release that is stable enough if all I care to do is add this > caching-strategy to a 1.0.X release featureset? > > Thanks for all the help! > > -Andrew > > > > > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 09, 2005 9:40 AM > To: OJB Users List > Subject: Re: Will a two-level cache solve this problem? > > Hi Andrew, > > > So, my question is will the introduction of a two-level cache isolate > >>clients of OJB from mutating the object that is in the real cache? > > > yep! > > > Are > > the objects that are in the local cache versus the global cache > > different references, or are they the same? > > > > They are different, the second level cache only deal with flat (no > references populated) copies of the persistent class objects. The used > CopyStrategy is pluggable. > > In OJB_1_0_RELEASE branch the first version of the two-level cache work > this way (will be included in next release). > > > > Is my only true option to go with an ODMG/OTM locking strategy to > > isloate my reads from writes? > > > > You could write an thin layer above the PB-api using the kernel locking > api in org.apache.ojb.broker.locking (OJB_1_0_RELEASE branch). > > regards, > Armin > > > Clute, Andrew wrote: > >>Hello all! >> >>I have a standard 3-tier webapp back with OJB in my business layer. We >>are using the PB API. We have a host of domain objects, that is passed >>up to the web tier and used for form manipulation. >> >>The standard pattern for us when editing an object is: >> >>1) Retrieve business object from PersistenceService >>2) Use object and integrate it to set form elements >>3) Place object into HttpSession for later >>4) On submit pass, take object out of HttpSession, and then populate >>date from form back into object >>5) Save object through PB >> >>We are using the default caching strategy as it provides us with the >>most amount of performance increase. A lot of our objects are static > > (we > >>are 90% read, 10% write) so we really want to keep that in place. >> >>However, the problem arises with the fact that the web app is munging >>with the same object reference that is in the cache! So, in my pattern >>above, while we are updating the object in Session, we are also > > updating > >>the object in the cache. We have gotten around it by every object we >>re
