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
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 no
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 perform
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 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,
RE: Will a two-level cache solve this problem?
Armin, you are a god! ;) Thanks for the information, all very cool! 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? How does this work when using Proxies for collections? 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)? I assume you need the FK's to accurately handle the copying between cache-levels. Does this all sound accurate? Thanks again, this 1.0.2 is really shaping up to be more than a point release! -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 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
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 return from OJB we clone. I really don't like that and want to get away from it. I know that one solution to this is ODMG and to implement read/write locks. I have been trying to stay away from that, only because it seems like I can't find a clean pattern to establish a write lock on the submit pass of a form when the object is in HttpSession. 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? Are the objects that are in the local ca
RE: Will a two-level cache solve this problem?
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. 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? 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? 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? I would also assume that JTA based TX won't make a difference? All very cool stuff! You mentioned that this will be included in the next release, but I assume you mean 1.1, and not 1.0.2, right? 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 > return from OJB we clone. I really don't like that and want to get away > from it. > > I know that one solution to this is ODMG and to implement read/write > locks. I have been trying to stay away from that, only because it seems > like I can't find a clean pattern to establish a write lock on the > submit pass of a form when the object is in HttpSession. > > 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? Are > the objects that are in the local cache versus the global cache > different references, or are they the same? > > Is my only true option to go with an ODMG/OTM locking strategy to > isloate my reads from writes? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 return from OJB we clone. I really don't like that and want to get away from it. I know that one solution to this is ODMG and to implement read/write locks. I have been trying to stay away from that, only because it seems like I can't find a clean pattern to establish a write lock on the submit pass of a form when the object is in HttpSession. 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? Are the objects that are in the local cache versus the global cache different references, or are they the same? Is my only true option to go with an ODMG/OTM locking strategy to isloate my reads from writes? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Will a two-level cache solve this problem?
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 return from OJB we clone. I really don't like that and want to get away from it. I know that one solution to this is ODMG and to implement read/write locks. I have been trying to stay away from that, only because it seems like I can't find a clean pattern to establish a write lock on the submit pass of a form when the object is in HttpSession. 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? Are the objects that are in the local cache versus the global cache different references, or are they the same? Is my only true option to go with an ODMG/OTM locking strategy to isloate my reads from writes?
