[JBoss Seam] - Re: My list of questions: Seam validation, transactions and
by gavin.kingï¼ jboss.com
"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
19Â years
[EJB/JBoss] - Single EJB w/ many actions or Multiple EJBs one for each act
by nuclaves
Hello,
I'm new to the world of EJBs and 3 tier development in general. I would appreciate any advice on designing a solution for the following scenario.
An application that lets users make requests for user account info, transaction history, order status, messages, etc.
Most of the data resides in another system and is retrieved by sending an xml request over http. The xml response is then transformed and presented to the end user.
I feel this can be accomplished in 2 different ways.
The 1st approach that springs to mind is to create an EJB/POJO for each request type and have them share a single EJB that handles the http communications.
The 2nd approach is to have a single EJB with an action for each request type and another EJB that handles the http communications.
My preference for the 1st approach is really based on my perception that it is cleaner and it makes more sense in a multi developer environment.
However, I can't help but have the feeling that in an EJB context, it may be more efficient to go with the 2nd approach. My thinking is that, maintaining a pool of a single EJB type would be more efficient than maintaining one with different types.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052857#4052857
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052857
19Â years
[EJB 3.0] - Single EJB w/ many actions or Multiple EJBs one for each act
by nuclaves
Hello,
I'm new to the world of EJBs and 3 tier development in general. I would appreciate any advice on designing a solution for the following scenario.
An application that lets users make requests for user account info, transaction history, order status, messages, etc.
Most of the data resides in another system and is retrieved by sending an xml request over http. The xml response is then transformed and presented to the end user.
I feel this can be accomplished in 2 different ways.
The 1st approach that springs to mind is to create an EJB/POJO for each request type and have them share a single EJB that handles the http communications.
The 2nd approach is to have a single EJB with an action for each request type and another EJB that handles the http communications.
My preference for the 1st approach is really based on my perception that it is cleaner and it makes more sense in a multi developer environment.
However, I can't help but have the feeling that in an EJB context, it may be more efficient to go with the 2nd approach. My thinking is that, maintaining a pool of a single EJB type would be more efficient than maintaining one with different types.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052856#4052856
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052856
19Â years
[JBoss Seam] - Single EJB w/ many actions or Multiple EJBs one for each act
by nuclaves
Hello,
I'm new to the world of EJBs and 3 tier development in general. I would appreciate any advice on designing a solution for the following scenario.
An application that lets users make requests for user account info, transaction history, order status, messages, etc.
Most of the data resides in another system and is retrieved by sending an xml request over http. The xml response is then transformed and presented to the end user.
I feel this can be accomplished in 2 different ways.
The 1st approach that springs to mind is to create an EJB/POJO for each request type and have them share a single EJB that handles the http communications.
The 2nd approach is to have a single EJB with an action for each request type and another EJB that handles the http communications.
My preference for the 1st approach is really based on my perception that it is cleaner and it makes more sense in a multi developer environment.
However, I can't help but have the feeling that in an EJB context, it may be more efficient to go with the 2nd approach. My thinking is that, maintaining a pool of a single EJB type would be more efficient than maintaining one with different types.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052855#4052855
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052855
19Â years