persistence@glassfish.java.net

Re: Determining if entity has been removed

From: Farrukh Najmi <farrukh_at_wellfleetsoftware.com>
Date: Tue, 09 Dec 2008 14:45:31 -0500

Markus KARG wrote:
>> Without going into gory details of my application here is my use case:
>>
>> * I have an existing entity in db
>> * Within a transaction the following occurs:
>> o The existing entity gets read by transaction
>> o The existing entity *MAY* get removed by transaction (or
>> not)
>>
>
> If it is the same transaction then you know very well what you did.

Because it is a fairly large code base with many components that fiddle
with persistent data and not every component of the code base knows what
any other component did.

> Why do
> you need JPA to tell you what your own code did?
>

Because EntityManager seems like the right place to keep track of
(manage) entity state.
I am quite sure that every EntityManagerImpl class has this information
available. So why not expose
it in a standard way via JPA? Whats the downside to doing that?

> If it is a differen transaction then you will not see the change anyways
> unless the transaction is finished, depending on the transaction isolation
> level. So JPA cannot know that the object is removed meanwhile.
>
>
>> o A new entity is inserted with the same id. The code to do
>> that needs to know whether to use a merge or insert.
>>
>
> You write "a NEW entity". So it will be a persist (= INSERT) always. Or do
> you mean a DETACHED entity?
>
>
>> One
>> way
>> to decide is to know if the netity was deleted or not. If
>> it
>> was deleted do an insert otherwise do a merge.
>>
>
> I think you do not mean "whether it was deleted" but rather "whether it does
> not exist currently", what can be easily solved e. g. by em.find().
>

I meant "whether it was removed via em.remove()". I already know that it
exists.

>
>> I am curious why there is no method(s) to determine state of en entity
>> within an EntityManager in the API.
>>
>
> Uh... there ARE several such methods...

Can you please tell me which ones are they?

> Maybe we just do not understand what
> you really want to do...?
>

I am not a JPA expert but just to be clear, I am not a newbie to JPA
either. I have built a fairly large scale service that does all kinds of
complex things with JPA such as versioning, replication across servers,
federated queries across servers, subscription and notification,
relational persistence of XML documents...

If I do not understand JPA by now then that would be really curious.

Thanks to you and other colleagues for sharing your experience.

-- 
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com