Would you see any obvious problems with this approach? On first glance it seems this could/should be done in all caches that keep the references across transaction boundaries.
hmm, maybe this approach will help to solve your specific problem, but (I assume your cache based on/extend a global used cache like ObjectCacheDefaultImpl) there some other problems to solve e.g. dirty reads when different threads operate on the same objects tx rollback, you have to remove all changed objects after rollback from cache
So I think using a global cache like ObjectCacheDefaultImpl is good for
read-only objects or apps with less update/delete operations and "user controlled"
cache.
In CVS version it is now possible to define the used ObjectCache implementation
in a per class manner. This should help to solve some problems
with caching. Next step is the upcoming two-level cache.
regards, Armin
On Wed, 15 Oct 2003 09:53:26 +0200, <[EMAIL PROTECTED]> wrote:
Hi Armin,
Thanks for the info!
Since I'm thinking of using my own ObjectCache implementation anyway (to use hard rather than soft references), I wonder if it would make sense to replace the collection attributes in the cache's cache() method. Pseudo code:
for each CollectionDescriptor cod in ClassDescriptor cld for myObject { coClass = cod.getCollectionClass(); if ( ! myObject.getTheCollection() instanceof coClass ) { coInst = coClass.newInstance(); coInst.addAll(myObject.getTheCollection()); myObject.setTheCollection(coInst); } }
Would you see any obvious problems with this approach? On first glance it seems this could/should be done in all caches that keep the references across transaction boundaries.
Regards, Gerhard
Armin Waibel <[EMAIL PROTECTED]> 14.10.2003 18:04 Bitte antworten an "OJB Users List"
An: OJB Users List <[EMAIL PROTECTED]> Kopie: Thema: Re: Initializing collection attributes
Hi Gerhard,
this is a known problem. Currently caching is not very sophisticated, but we will start to implement a really smart two level cache in near future. This new cache implementation should solve most known problems.
Currently the user have to take care of a consistent cache.
regards, Armin
On Tue, 14 Oct 2003 15:23:36 +0200, <[EMAIL PROTECTED]> wrote:
Hi,1:n
I ran into a problem with implementing the collection attribute for amapping:
Since I didn't want to "polute" my persistent objects with any ODMG or even OJB specific imports, I just initialized my collection attributes (of type java.util.List) with ArrayLists when needed. This worked fine as long I was using a ObjectCachePerBrokerImpl cache, because when the transaction that created the object committed, the cache was cleared. So the next time the object was accessed, it was read fresh from the database and OJB set the collection attribute to a RemovalAwareCollection (or whatever the class descriptor specified).
Now I'm trying to use a ObjectCacheDefaultImpl -- with the result that the new object is still cached when I access it again, and still has the ArrayList as List implementor of the collection attribute. The consequence is that removing entries from the List does not work, because OJB never gets notified of the removal.
Who knows a way to initialize collection attributes with the proper OJB collection classes without making the object model dependent on OJB? Thanks for any hints!
Gerhard
--------------------------------------------------------------------- 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]
