db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Armin Waibel" <ar...@code-au-lait.de>
Subject Re: repost, RE: how to implement a TwoLevelCache
Date Wed, 01 Oct 2003 00:55:02 GMT
Hi,
----- Original Message -----
From: "Matthew Baird" <Matthew.Baird@motiva.com>
To: "OJB Developers List" <ojb-dev@db.apache.org>
Sent: Tuesday, September 30, 2003 7:30 PM
Subject: RE: repost, RE: how to implement a TwoLevelCache


> I forgot to add that I think some of the OTM stuff does belong in the
PB api.
agree, e.g. the copy-package should be part of the kernel
in the case of implementing a two-level cache (and the swizzling
stuff too, to deal with pc object references?).

>But
> in some cases to do things right might mean having to change the PB
api's.
I propose to extend the PB interface and add additional
internal services/methods

interface InternalPersistenceBroker extends PersistenceBroker
{
// additional intern used services and methods
}

and let PB-kernel deal with IPB instances (and if useful the
top-level api's too).
This can help us to avoid changes on PB user api level
and make it possible to refactor the existing PBImpl
class (loc-monster) step by step.
What do you think?

regards,
Armin

m

-----Original Message-----
From: Matthew Baird
Sent: Tuesday, September 30, 2003 9:59 AM
To: OJB Developers List
Subject: RE: repost, RE: how to implement a TwoLevelCache


Hi Oliver,

The reason for cloning is to make a copy that exists only in that
transactional context, thus it is isolated. If we work upon a reference,
someone else might have a reference to that object and start to see your
changes before commit time.

as for the swizzling tests, probably the best illustration of what they
do is given if you reimplement the tests using the PB api. That should
be reasonable easy to do. Nothing like the real world to explain what's
going on.

-----Original Message-----
From: oliver.matz@ppi.de [mailto:oliver.matz@ppi.de]
Sent: Tuesday, September 30, 2003 1:43 AM
To: ojb-dev@db.apache.org
Subject: RE: repost, RE: how to implement a TwoLevelCache


Hello Armin,

> -----Original Message-----

> your proposal. All objects in OTM were cloned (using
> ObjectCopyStrategy interface implementations)
> except objects with write lock (hope I tell the truth).

I like the idea of keeping the cloning strategy separate.
However, I think that stuff is misplaced in the OTM layer
but should be part of the PB layer.

> I agree Thomas that the cloning of objects is evil.

I would like to understand that.  Can you explain it
more detailed?

I have had a look at the swizzling tests that Matthew
mentioned, but still I do not understand the problem.

> E.g. say object A has a reference using proxy, the real object
> is materialized but the real object itself is not serializeable but
> has a clone/copy method ... ok, this can be solved use writeObject/

Sorry, I do not understand that scenario.  Is it the following?

  You clone object A, which has a materialized proxy reference,
  say to object B.
  B is not serializable, but has a clone method.

I do not see what this topic has to do with serialization.
What I would like to do in this case is to clone the object
and thereby (or afterwards) replace the reference by an
independent proxy or by null.

As I pointed out in my other mail a few days ago, I propose
to not let the cloned objects reference each other or anything
else.

> readObject methods in IndirectionHandler or declare real subject
> as transient.
> Or object A has a collection of B objects. For A we use serialization
> as copy strategy but the B objects use another copy strategy ....

The bad thing about serialization is that it recursively follows
references, therwby possibly creating unwanted copies.

If you can explain it to me more easily in German, then go ahead.

One problem that I do see arises when you clone collections
because they may (depending on the O/R-mapping) change unexpectedly,
so the cache becomes inconsistent. I wrote that in my previous mail,
too.

regards,
Olli

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org






---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message