J2EE - entities - When do JPA entity units get saved into thedatabase

Discussion in 'Java' started by Taras_96, Apr 28, 2008.

  1. Taras_96

    Taras_96 Guest

    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
     
    Taras_96, Apr 28, 2008
    #1
    1. Advertising

  2. On Apr 28, 3:31 am, Taras_96 <> wrote:
    > 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


    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
     
    Owen Jacobson, Apr 28, 2008
    #2
    1. Advertising

  3. Taras_96

    Taras_96 Guest

    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 <> 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
     
    Taras_96, Apr 29, 2008
    #3
  4. On Apr 29, 10:33 am, Taras_96 <> wrote:
    > 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 <> 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?


    Yes.

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


    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.

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


    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.

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


    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
     
    Owen Jacobson, Apr 29, 2008
    #4
  5. Taras_96

    Taras_96 Guest

    On Apr 29, 11:06 pm, Owen Jacobson <> wrote:
    > On Apr 29, 10:33 am, Taras_96 <> wrote:
    >
    >
    >
    > > 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 <> 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?

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

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

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

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


    It clears it up considerably.

    So basically with a EJB 2 entity bean, because the actual object is
    stored on the server, and all client accesses are remote methods, then
    the object is always synched with the database.

    With EJB 3 entities changes are synched with the database only if the
    bean is loaded (using the entity manager) and subsequent changes are
    made in the same transaction AND the object was not passed across a
    remote interface.

    As bean methods automatically define the boundaries of transactions
    (unless configured otherwise), and changes made within a bean method
    which also loads the entity will have those changes automatically
    synched with database (eg: using a session bean as a DAO, like in your
    example) ONLY IF the bean instance and the entity object exist in the
    same address space (ie: the bean instance does not access the entity
    remotely).

    In summary, changes are automatically synched if:

    - always for EJB entities
    - for 3.0 entities, the following has to be true:
    * the object was not accessed remotely (the object was not copied
    across a remote interface - this is avoided if you use a session bean
    existing in the same address space as the entity bean as a DAO)
    * the changes made were made in the same transaction as when the
    entity was loaded

    However, I still don't fully understand the difference between persist
    and merge. You wrote that merge:

    ""reattaches" it to the database (in the process persisting changes
    from the entity into the database and vice-versa)."

    You wrote 'reattaches' - is something more done than simply synching
    the entity object with the database? You also wrote that changes may
    be passed *from* the database *to* the entity. Does this occur if a
    database field is changed through another interface (possibly through
    another entity object), and the fields in the entity object need
    updating (as well as any data changed in the entity object needs to be
    transferred through to the database)? Wouldn't this create concurrency
    problems, where two entity objects may be changing the database at the
    same time?

    eg:

    1. load and change the entity object.
    2. do some other stuff. During this time another machine alters the
    database.
    3. merge the original entity object.

    You wrote about persist:

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

    By 'attaches' do you mean that any subsequent changes made to the
    entity object will be automatically synched with the database (as long
    as the changes are made in the same transaction)? You also write that
    'it stores the entity' - so is persist only used for objects that
    currently are not in the database (are not persistent objects)? I
    don't know if this is correct as I've seen code which finds an entity,
    then calls persist on the result returned..

    Both methods seem to 'attach' the object to the database, so I'm not
    quite sure of the difference. Perhaps merge is used on objects that
    have not yet had 'persist' called on them?

    Two slightly unrelated questions:

    1. What is the Local(Frobnicator.class) syntax (I have seen the @Local
    and @Remote decorators, but without any following text)?
    2. In EJB 2.0, session beans and message beans may be represented by
    multiple bean *instances* (and exist in a pool - EJB objects are
    attached to the bean instances when required). To ensure
    synchronisation and concurrency, is only ever one *instance* exist of
    an entity bean, with multiple interfaces (EJB objects) being attached
    to the same bean instance?

    Thanks again

    Taras
     
    Taras_96, May 4, 2008
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Ward
    Replies:
    0
    Views:
    557
    Chris Ward
    Sep 12, 2007
  2. redbull
    Replies:
    2
    Views:
    739
    Kenneth P. Turvey
    Oct 31, 2007
  3. markla
    Replies:
    1
    Views:
    552
    Steven Cheng
    Oct 6, 2008
  4. Amit Jain
    Replies:
    3
    Views:
    1,757
  5. Jim Higson
    Replies:
    3
    Views:
    226
    Eric Amick
    Jul 25, 2004
Loading...

Share This Page