db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Baird" <Matthew.Ba...@motiva.com>
Subject RE: repost, RE: how to implement a TwoLevelCache
Date Tue, 30 Sep 2003 16:58:42 GMT
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


Mime
View raw message