Hi Armin,
I certainly look forward to the upcoming cache improvements. The
cache-by-class feature is very useful and I already use it to distinguish
between basically static and more dynamic data.
Regards,
Gerhard
Armin Waibel <[EMAIL PROTECTED]>
16.10.2003 16:28
Bitte antworten an "OJB Users List"
An: OJB Users List <[EMAIL PROTECTED]>
Kopie:
Thema: Re: Antwort: Re: Initializing collection attributes
Hi Gerhard,
> 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,
>>
>> I ran into a problem with implementing the collection attribute for a
> 1:n
>> mapping:
>>
>> 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]
