Sever Session Cache, Read-Only

Question

Since the objects in the server cache are shared, we should not modify the objects in cache. We are thinking of enforcing this in a programmatic way.
Does TopLink have a plan to enhance the current caching capability by allowing user to config the cache to be read-only, read-write, ... thus updates to the read-only cached objects (and possibly their associations) are not allowed? Or is this just too difficult for TopLink to implement?
Thanks a lot for your information.
Haiwei

Answer 1

Doug,
Please excuse my ignorance. But how does setting the flag on the postBuild() descrirptor method prevent anybody from modifying the server session object ?
I presume I have a class that is generic - PeristentObject that has a filed isEditable and I set this flag to false when the object is being built. But how can that help me from not modifying the cached object as I like ? I am free to invoke the setters am I not ?
Regards,
Aswin.
Haiwei,
TopLink has made some great enhancements to caching
and cache coordination in 10.1.3. Take a look at the
10.1.3 preview 3 for more details.
The Server cache's objects are to be considered
read-only. The UnitOfWork provides working copes
where changes are made and these are merged into the
shared cache on write. They are just read only to
prevent direct modification outside of a
transactional context.
I have worked with customers who maintained a flag on
their objects to know if setter should be permitted.
This was set to false (disallowing access) using the
postBuild descriptor event and then set to true
during the postClone method to allow modifications in
the UOW working copies. Its a little intrusive but
more portable then injecting a bunch of proprietary
TopLink code into your model.
Going forward we are looking at some simplification
solutions using AOP to eliminate the visibility of
the UnitOfWork and working copies so all of this is
automated behind the scenes. We hope to also preview
this when its available.
Doug