-
1. Re: Understanding how to implement an atomic web transaction with Seam
jeanluc May 30, 2009 4:11 PM (in response to thekonstantin)One comment: with an extended persistence context you should not need to use merge(), the whole idea of an extended PC is to avoid that call. The changes accummulate in the Java object during the wizard which, at the end signalled by flush(), are persisted to the db. There is no intermediate merge() - that's the behaviour Seam tries to avoid.
-
2. Re: Understanding how to implement an atomic web transaction with Seam
amitev May 30, 2009 4:35 PM (in response to thekonstantin)And here is a whole article on
.
When - and when not - to use the JPA merge method -
3. Re: Understanding how to implement an atomic web transaction with Seam
thekonstantin May 30, 2009 6:34 PM (in response to thekonstantin)Jean and Adrian, thanks for your help. I've understood this and it sounds logically.
But in my situation I want to add a new object in this wizard. Before rendering the first page I initialize a new entity. During the conversation I want to add and modify several entities. At the end of conversation I want to decide whether the modifications should transfered to the database or not.
What is the best practice for this intention? Does my application have to
keep in mind
which should be added via em.persist(...) before em.flush() to do this at the end of transaction? It sounds not very comfortable.The main question is: How can I add an entity to the persistence context without writing the entity directly to the database?
Cornelius
-
4. Re: Understanding how to implement an atomic web transaction with Seam
jeanluc May 31, 2009 7:21 AM (in response to thekonstantin)Adding an entity to a context (i.e. making a transient entity persistent) is done via persist() and this operation only causes an immediate real write to the db (as opposed to one delayed until the flush) if the id of the entity is generated at insert-time. This is because persist() is required to return that id. When using Oracle sequences, for instance, there is no need for an immediate write because the JPA provider can read the next value from the sequence separate from the writing of the entity. With other id generation schemes, however (such as databases with auto-increment fields), a write operation is needed.
Which database and id generator are you using/
-
5. Re: Understanding how to implement an atomic web transaction with Seam
thekonstantin May 31, 2009 11:07 AM (in response to thekonstantin)
Jean Luc wrote on May 31, 2009 07:21:
Adding an entity to a context (i.e. making a transient entity persistent) is done via persist() and this operation only causes an immediate real write to the db (as opposed to one delayed until the flush) if the id of the entity is generated at insert-time. This is because persist() is required to return that id. When using Oracle sequences, for instance, there is no need for an immediate write because the JPA provider can read the next value from the sequence separate from the writing of the entity. With other id generation schemes, however (such as databases with auto-increment fields), a write operation is needed.Yes! This is the solution for my problem!
Jean Luc wrote on May 31, 2009 07:21:
Which database and id generator are you using/I'm using a MySQL database during development. I haven't specified a GenerationType (which means auto, I think.) I've changed the GenerationType to Table and it works like I want! (Sadly, MySQL doesn't support sequences.)
Thank you very much for your help!
Cornelius