True.


Yep check the glassfish-persistence website.
Oracle donated toplink essentials to the glassfish project which is sun's reference implementation of J2EE5. So it's open source.



As I understand it, the identity map ensures that within a single session, you always get the same object instance for each entity. So it relates to the session cache.
Not sure how this relates to the unit of work cache. Units of work are basically transactions right?

Tom.

I asked about the TopLink caching features on the Glassfish persistence dev mailing list.

Apparently TopLink essentials is just focusing on the JPA implementation whereas TopLink commercial adds more features such as distributed second level cache, query cache, non-RDB mappings etc.

The person who responded stated that it is possible to utilize the caching features you pointed to (e.g. Weak Identity Map) with the JPA implementation but they only affect the 2nd level cache (referred to as the sesssion cache in the TopLink documentation). They do not apply to the JPA persistence context. The persistence context should apparently be maintained until it is cleared or closed according to JPA spec.

So this would mean that a single JPA Toplink EntityManager/session for an application would suffer from similar memory issues as trying to maintain a long lived Hibernate session.

Also, I don't think it would be possible to utilize the 2nd level cache to 'magically' keep the UI in sync as with JPA whenever you update a detached object (via merge), you get back a new object.

So I think the options are the same as before:

1. Maintain a single long lived session and manually evict objects when no longer needed (Don't think this is possible with JPA, only with raw Hibernate - and possibly raw Toplink) - probably difficult to manage.

2. Maintain a single long lived session and make sure you have lots of memory for all possible use cases ....? Unlikely.

3. Use single Entity Manager per interaction and handle reattaching objects as appropriate and events to update UI. This is essentially what you'd have to do if you were using a non-ORM approach.

I think we'll probably have to go for approach 3 - guess there is no such thing as a free lunch!

Thanks for your input though.
Martin

Interesting.

I think what I've been trying to communicate is something like this :
http://www.oracle.com/technology/products/ias/toplink/doc/10131/main/_html/sesun009.htm

You have to pay for this technology though.

You can use EclipseLink (http://wiki.eclipse.org/EclipseLink/Use ... e_Concepts) or ObjectDB, they support having the session automatically evict unreferenced unchanged objects.

Personally, I have never understood why one would design a persistence layer that can lazy load objects, but not automatically release them. Seems like only half a solution.

My best guess is that the use case with the most attention is those enterprisey web apps, and people keep forgetting about the old style fat clients.

As an example I would recommend trying to create an iPhoto-like Java application with Hibernate, that displays 100,000 photos in a continuous (non-paged) scroll view. This will be very hard without weak reference support in the session. You'll end up getting lost in a maze of evicts, merges, locks and updates. Basically Hibernate forces all the ugly work on you, instead of helping you, and you end up doing some kind reference tracking, something most of us thought they were done with when they started programming in Java.