Hello Adam,
An application managed EntityManager always wraps an Extended Persistence Context. An Extended Persistence Context is not released until the EntityManager is closed unlike a transactional Container Managed Entity Manager which releases the Persistence Context at the end of each transaction.
If you need you can simulate the transactional EntityManager by calling flush(), clear() before each commit() but this would still leave you with the detached issue.
The problem with holding the objects in a weak reference is the change detection requirement of the PersistenceContext. Any object touched by the PersistenceContext must be tracked by the PersistenceContext and any changes to that object must be written to the database on request, even if the object is no longer referenced by the application. With weak references unwritten changes could potentially be lost.
There a multiple ways you could manage the volume of object registered within a Persistence Context. On screen changes you could close and create a new EntityManager but my recomended approach would be to detach the display objects from the managed objects. No need to create seperate classes but you could use the merge facility of the EntityManager to merge the objects from the GUI to the PersistenceContext for any object updates or specific save events from the GUI. This would limit the number of objects in your PersistenceContext and mostlikly provide for a performance improvement from your current design as less objects are being checked for changes. I would also recommend that if you took this approach that you switch the shared cache to be a softcache weak identity map.
--Gordon
-----Original Message-----
From: Adam Bien [mailto:abien_at_adam-bien.com]
Sent: Monday, November 19, 2007 11:46 AM
To: gordon.yorke_at_oracle.com
Cc: persistence_at_glassfish.dev.java.net
Subject: Re: Configuration of Client vs. Shared Cache
Hi Gordon,
thank you very much for the fast reply. I'm thinking of the Persistence
Context as an Identity HashMap, which primary goal is to keep the
consistency of the entities in a transaction.
However in our application (it is a rich client, which connects directly
to the database without an application server or middleware), it seems
like once loaded objects are hold
by the EntityManager until the method clear is invoked or the Entity
Manager is closed (we are using the current build - TopLink v2b58). The
Entity Manager remains open between the transactions - it is even not
cleared. We would like to work with the entities, without loading them
from the database every time.
We are using data binding between the domain objects and the UI - so
clearing the entity manager makes the entities detached (and makes the
GC run) - the whole app has to be refreshed then. This in turn is not
wished by the end users :-).
I'm wondering, whether it would be possible to hold the objects using
weak-reference in the L1 cache / transactional cache. Then all unneeded
objects would be automatically garbage collected. The object-identity
would be still provided with this setting... Now the memory consumption
increases - until Out Of Memory occurs...
any thoughts?
thank you in advance,
regards,
adam
Gordon Yorke schrieb:
> Hello Adam,
> You may be confusing the Persistence Context with a cache?
> Sometimes the UnitOfWork which is the implementation of the
> Persistence Context in TopLink is described as a cache to explain some
> of its behaviours but its behaviour is beyond that of a cache.
> Because the Unit0fWork must track all objects that were ever read
> through or registered by the UnitOfWork to full its behavioural
> requirements the TopLink cache settings do not apply.
> --Gordon
>
>
> Adam Bien wrote:
>> Hi All,
>>
>> TopLink cache consists of two parts:
>> 1. Client/L1
>> 2. Shared/L2
>>
>> Is it possible to configure them independently? In the TopLink
>> reference there are two sections:
>>
>> http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#BABGDJBC
>>
>>
>> It seems like the @Cache annotation addresses the Client/L1 cache.
>> The properties (
>>
>> eg. <property name="toplink.cache.type.Order" value="Full"/>) the L2.
>>
>> Is it possible to configure both caches using the persistence.xml
>> properties?
>>
>> I would like to configure Weak Caches for both levels, however it
>> seems like the L1 cache is still "Full" (or it uses "hard" references
>> to entities)
>>
>> thank you in advance!,
>>
>> adam bien
>>
>
--
Consultant, Author, Java Champion
Homepage: www.adam-bien.com
Weblog: blog.adam-bien.com
eMail: abien_at_adam-bien.com
Mobile: 0049(0)170 280 3144
Books: Enterprise Architekturen (ISBN: 393504299X),
Java EE 5 Architekturen (ISBN: 3939084247),
J2EE Patterns, J2EE Hotspots, Enterprise Frameworks and Struts