J2EE - entities - When do JPA entity units get saved into the database

J2EE - entities - When do JPA entity units get saved into the database

Post by Taras_9 » Tue, 29 Apr 2008 16:31:25


i all,

I'm trying to gain a better understanding of some J2EE concepts, in
particular entities. AFAIK, if you make changes to an object using a
CMP Entity Bean, those changes are written to the database
automatically:

Customer customer =
// ... obtain a remote
//reference to the bean
// get the customer's address
Address addr = customer.getAddress();
// change the zip code
addr.zip = "56777";
// update the customer's address
customer.setAddress(addr); <- the address field in the database has
now been updated

In 'Java EE with Glassfish application server', the author writes:

"
customer3 = entityManager.find(Customer.class, 4L);
customer3.setLastName("Johnson");
entityManager.persist(customer3);
"

What is the purpose of the 'persist' method, and how is it different
to the 'merge' method? Notice that in the EJB 2.1 code, I didn't have
to explicitly tell the code to update the DB, this was done
automatically.

Furthermore, the book uses a Session Bean to implement a DAO to the
JPA unit:

@Remote
public interface CustomerDao
{
public void saveCustomer(Customer customer);
public Customer getCustomer(Long customerId);
public void deleteCustomer(Customer customer);
}

what is the purpose of the 'saveCustomer' method? Do you have to
explicitly tell the code to save any changes made to objects that are
stored in a database?

eg:

Customer cust = dao.getCustomer(1);
cust.setLastName('foo');
dao.saveCustomer('cust');

I thought the point of CMP was so that you didn't have to explicitly
save objects; that any changes made to the objects in the code were
automatically reflected in the database representation of the object.
The 2.1 code automatically updates the appropriate field, whereas in
the 3.0 code you have to explicitly call save - in 3.0 do you have to
explicitly save changes to the database, whereas in 2.1 this was done
for you by using the Entity Bean?

Thanks

Taras
 
 
 

J2EE - entities - When do JPA entity units get saved into the database

Post by Owen Jacob » Tue, 29 Apr 2008 23:04:03

n Apr 28, 3:31m, Taras_96 < XXXX@XXXXX.COM > 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. (For local calls,
neither EJB 2 entity beans nor JPA entities are remoted, so none of
this is relevant.)

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).
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.

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

 
 
 

J2EE - entities - When do JPA entity units get saved into the database

Post by Taras_9 » Wed, 30 Apr 2008 23:33:50

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...




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?


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?


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


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
 
 
 

J2EE - entities - When do JPA entity units get saved into the database

Post by Owen Jacob » Thu, 01 May 2008 00:06:33

n Apr 29, 10:33m, Taras_96 < XXXX@XXXXX.COM > wrote:

Yes.


Using EJB 2 entity beans, calling a finder method is "loading the
entity". Using EJB 3/JPA entities, calling EntityManager.find (...)
loads the entity, as do the various query methods.


Sometimes.

If there isn't already a transaction going on, then yes, each of those
set methods may take place in its own transaction (subject to the
transaction settings in ejb-jar.xml). If there's already a
transaction in progress (either BMT or CMT), then the set methods will
usually participate in the ongoing transaction.

However, if the value of 'bean' escapes out of an ongoing transaction,
and then later someone calls setFirstName, that call will still update
the database.

Not so with JPA entities: when an entity reference exists past the end
of the transaction that created it, the entity is "detached" from the
database and changes to it affect only the object, not the database;
hence the EntityManager.merge method for "reattaching" detached
entities.


Let's say you have a stateless session bean PersonDAO:

@Stateless
@Local(PersonDAO.class)
public class JPAPersonDAO implements PersonDAO {

@PersistenceContext
private EntityManager em;

public Person getPersonByName (String firstName) {
return em.find (Person.class, firstName);
// (a)
}
}

If this EJB is called directly by a servlet and no UserTransaction
code is involved on the servlet side, then at (a) the resulting Person
object is detached from the database (as the container-managed
transaction for the EJB method call ends).

Now let's introduce a second EJB:

@Stateless
@Local(Frobnicator.class)
public PersonFrobnicator implements Frobnicator {
@EJB
private PersonDAO dao;

public void frobPersonByName (String name) {
Person p = dao.getPersonByName (name);
p.setNote ("I've been frobbed!");
}
}

When something outside the EJB container calls frobPersonByName, the
container starts a transaction, which propagates into the methods
called from frobPersonByName. Because the Person object looked up
from the DAO was looked up in the same transaction it's being modified
in and is not being passed across a remote interface, the change to
the note property will be persisted to the database.

If the JPAPersonDAO EJB declared its interface as
@Remote(PersonDAO.class) instead, the returned Person would be
detached even though the transaction it was loaded in hasn't
completed, and there would need to be an explicit save step where the
modified Person is sent back to the DAO to be saved to the DB.

Does that clear it up at all, or does it make things worse?

-o