If I get an EM instance from EntityTransaction (or the event) I would be perfectly happy with it :-)
On 23.06.2011, at 21:24, Gordon Yorke wrote:
> Having a PersistenceContext event listener that included transaction events would be better.
> --Gordon
>
> Pinaki Poddar wrote:
>>
>> Hi,
>> To complement the current proposal on access to the managed entities filtered by their life cycle states (and flush state - which as per earlier comment of Michael Bouscher is not strictly a life cycle state, and I agree), we could consider a Transaction listener plug-in point for the application.
>>
>> Current listeners are tied to entity life cycle, not transaction. In combination, many use cases that are mentioned by Adam Bien and others could be addressed, I believe.
>>
>>
>> Regards --
>>
>> Pinaki Poddar
>> Apache OpenJPA Project Chair http://openjpa.apache.org/
>> JPA Expert Group Member
>> Application & Integration Middleware
>>
>>
>>
>>
>>
>>
>>
>>
>> From: Adam Bien <abien_at_adam-bien.com>
>> To: Linda DeMichiel <linda.demichiel_at_oracle.com>
>> Cc: jsr338-experts_at_jpa-spec.java.net
>> Date: 06/23/11 01:35 AM
>> Subject: [jsr338-experts] Re: Standardized Access to ChangeSet
>>
>>
>>
>> Hi Linda,
>>
>> I like Pinaki's proposal now better than my - lets go with his suggestion (I'm not sure about the includeSubclasses):
>>
>> <T> Set<T> getEntities(Class<T> entityType, boolean includeSubclasses, LifeCycleState... states);
>>
>> If hard to implement - we could return "dehydrated" Entites as suggested by Emanual.
>>
>> Top 5 Use Cases:
>>
>> 1. Implementation of cache synchronization
>> 2. Transparent synchronization between RIA apps and serverside EMs
>> 3. Auditing
>> 4. Versioning / Historization
>> 5. Delta Computation for efficient object transfer (similar to 2)
>> 6. Debugging / Unit Testing purposes
>>
>> thanks!,
>>
>> adam
>> On 21.06.2011, at 17:57, Linda DeMichiel wrote:
>>
>> Hi Adam,
>>
>> Thanks for raising this issue and your initial proposal. Now that the
>> group has iterated over it, I think it would be very helpful if you
>> could put together a revised one in terms of what functionality / APIs
>> you would like to see added in view of the discussion. I think having
>> something very concrete to discuss will help us converge.
>>
>> thanks,
>>
>> Linda
>>
>>
>> On 6/21/2011 4:56 AM, Adam Bien wrote:
>> HI Gordon,
>> On 20.06.2011, at 20:12, Gordon Yorke wrote:
>>
>> Hello Adam,
>> Would the "dirty" set include unsynchronized persisted and removed Entities? It would likely be better to have separate sets for these.
>>
>> Separation would be even better. In the past I just accessed TopLinks internals to get this information :-). removed and unsychronized entities are also important if you would like to implement a cache coordination (like Eclipse Link), or something like Envers.
>>
>> Without configuration these sets would have to be cleared as the EntityManager is cleared. What effect do you see EntityManager.clear() having on these sets?
>>
>> IMHO the results should be empty after a clear. But I'm open for any suggestions: I never implemented a JPA provider by myself entirely :-)
>>
>> As an alternative to the sets an EntityManager lifecycle listener could be notified of the sets on EntityManager.flush() and the application could track the same sets as need across flushes.
>>
>> EntityListener is also fine - explicit methods, however, are more straight forward to use.
>>
>> --adan
>>
>>
>> --Gordon
>>
>>
>> Adam Bien wrote:
>> HI All,
>>
>> I would like to propose additional EntityManager methods:
>>
>> Set<Class> updated = EntityManager#getUpdatedEntities(Class<T>.class);
>> Set<Class> deleted = EntityManager#getDeletedEntities(Class<T>.class);
>> Set<Class> created = EntityManager#getCreatedEntities(Class<T>.class);
>> Set<Class> dirty = EntityManager#getDirty(Class<T>.class);
>>
>> We had to use provider-specific EntityManager extensions to access the dirty entities for the implementation of replication or historization.
>>
>> Such methods would be also useful for debugging purposes,
>>
>> thanks in advance,
>>
>> adam
>>
>>
>>
>>
>>
>>
>>