"beligum" wrote : 0. If I inject (@In) my EntityManager in Seam, it holds an 
extended persistence context, right?

If there is a long-running conversation, yes.

"beligum" wrote : 1. If I call merge() or not in the update() method, it 
doesn't make any difference, the changes are always written to the DB. Why is 
that?

merge(x) is a no-op if x already belongs to the persistence context (which is 
usually the case when you have an extended persistence context.

"beligum" wrote : 2. I use seam-validation that checks my data, but when 
something goes wrong in the update() method, a rollbackException is thrown, but 
my changed data is still written to the DB. How come?

Um, I don't really follow this. Seam validation does not throw rollback 
exceptions.

Probably the reason the changes are already persistent is because they were 
applied to the model, and then persisted, on previous async validation requests.

"beligum" wrote : 3. If I would like to solve the issue in question #2, if 
@Begin(flushMode=MANUAL) the only solution?anonymous wrote : 
  |   | 
  |   | No, there are two other solutions. 
  |   | 
  |   | (1) use <a:support bypassUpdates="true"/>
  |   | (2) disable Seam transaction management and use EJB transaction 
management instead
  |   | 
  |   | I do not recommend (2).
  |   | 
  |   | "beligum" wrote : If you have an answer here, please elaborate 
regarding @TransactionAttribute and @Rollback, because this is all but clear to 
me. For instance, why doesn't my @Rollback on the update() method work if 
something goes wrong in that method?
  |   | 
  |   | Probably it does, but the changes were persisted from a previous async 
validation request. But I can't really say, from the information given.
  |   | 
  |   | "beligum" wrote : 4. Is this solution: 
http://docs.jboss.org/ejb3/app-server/tutorial/extended_pc/extended.html the 
same as @Begin(flushMode=MANUAL)?
  |   | 
  |   | That is one good solution, yes. Another possibility is 
bypassUpdates="true". 
  |   | It is a (fixed) mistake that seam-gen in 1.2.1 did not use 
bypassUpdates.
  |   | 
  |   | I think you should start by trying bypassUpdates.
  |   | 
  |   | "beligum" wrote : 7. A bit of a general question: in my scenario 
(without the manual flushmode), where are the transactions started/ended, and 
where will throwing runtime exceptinos do any rollback on the changed data?
  |   | 
  |   | I don't know for sure. Are you using TransactionSeamPhaseListener? If 
so, they are tied to the lifecycle of the JSF request, as in the docs.
  |   | 

View the original post : 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052861#4052861

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052861
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to