Re: J2EE - entities - When do JPA entity units get saved into the database
- From: Taras_96 <taras.di@xxxxxxxxx>
- Date: Tue, 29 Apr 2008 07:33:50 -0700 (PDT)
Hey Owen,
I reckon that what you've mentioned are the answers that I'm looking
for, but your post doesn't entirely make sense to me...
On Apr 28, 10:04 pm, Owen Jacobson <angrybald...@xxxxxxxxx> wrote:
It's unfortunate (but understandable) that the EJB 3 persistence spec
reused the term "entity", as JPA entities and EJB 2 Entity Beans have
almost nothing to do with one another beyond "they map to the
database".
EJB 2 entity beans are full-blown remote objects; when you return an
entity bean from an EJB, the code receiving it may actually receive a
remote stub pointing to a server object. JPA entities are merely
serialized as-is and returned across remote calls.
What does this mean? That a a remote client obtaining a EJB3 bean will
obtain a copy of the object, whose methods will actually operate on
the copy rather than being stubs?
Both JPA entities and EJB 2 entity beans will automatically persist
field changes back to the database if the changes occur within the
same transaction that the entity was loaded in AND if the object has
not passed across a remote method call (even within the same JVM).
What do you mean by loading the entity? Could you give a couple of
examples of changes that do and changes that do not occur in the same
transaction?
EJB 2 entity beans will also automatically persist changes back even
after the transaction has completed or when referenced across a remote
interface, at the cost of making every method call on the entity a
remote method.
Does this mean:
MyBeanHome home = // get a reference to MyBeanHome
MyBean bean = home.find(someKey); // <- is this what you mean by
'loading the entity'?
bean.setFistName("foo"); // <- here a transaction has completed
bean.setLastName("bar"); // <- here *another* transaction has been
completed
The EntityManager merge method takes a JPA entitiy that has been
allowed to escape its original context, either by being passed or
returned across a remote interface or by surviving past the end of the
transaction that originally loaded it, and "reattaches" it to the
database (in the process persisting changes from the entity into the
database and vice-versa). The persist method does what it says on the
tin: it stores the entity in the database as-is (and attaches it to
the database within the transaction).
-o
This last paragraph doesn't really make sense to me.. do you know of
any resources that explain this well (eg: what do you mean by
'original context'? Or 'surviving' past the end of the transaction
that originally loaded it?)
Thanks
Taras
.
- Follow-Ups:
- Re: J2EE - entities - When do JPA entity units get saved into the database
- From: Owen Jacobson
- Re: J2EE - entities - When do JPA entity units get saved into the database
- References:
- J2EE - entities - When do JPA entity units get saved into the database
- From: Taras_96
- Re: J2EE - entities - When do JPA entity units get saved into the database
- From: Owen Jacobson
- J2EE - entities - When do JPA entity units get saved into the database
- Prev by Date: Lockable JFrames?
- Next by Date: Questions about drawing on Canvas
- Previous by thread: Re: J2EE - entities - When do JPA entity units get saved into the database
- Next by thread: Re: J2EE - entities - When do JPA entity units get saved into the database
- Index(es):
Relevant Pages
|
