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]



Reply via email to