[JBoss Seam] - Exception handling of PersistenceException
by dapeng
Hi,
Hibernate executes the statements only on flushing, which is most of the time at the end of a tx. It means, any database related exception (foreign key constraint or unique constraint etc.) will be thrown in a deferred fashion(not at the time of invocation, but at the time of tx commitment). At the end of the 5 and 6 JSF phases, a TransactionRolledBackException is thrown, when all action methods have been executed. There is no chance to catch such kind of ConstraintException in service layer or in JSF actions.
What is the best-practice for handling these exceptions?
The normal behaviour I excpeted from the system is to add a faces message and stay on the same view. I think the only guy who can do this job is a ExceptionHandler. First question is why not allow to add user defined ExceptionHandler? Second question is: Can I use any of the existing handler to implement the desired behaviour? In the documentation I only see examples which redirects to another view. Is there a shortcut (EL-expression) to find out the current view and use it as thre redirection target? If not, I would like to implement it. My plan is to use a PhaseListener to catch the current view and put it somewhere (request attribute or thread locale, anyway, anywhere reachable by a EL-expression) for later use and configure in the pages.xml
<exception class="javax.persistence.PersistenceException">
| <end-conversation/>
| <redirect view-id="{el-expression-to-the-current-view}">
| <message>Database access failed</message>
| </redirect>
| </exception>
|
I would like to know your opinions to the solution. Whether you have better suggestion or see general problems
thx for your feedback!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103756#4103756
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103756
18 years, 8 months
[JBossCache] - Serialization
by FredrikJ
Hi.
We have been hunting hot spots in our application which relies heavily on the jboss cache. One hot spot that occurred was in the actual serialization of the objects. We got rid of the hot spot by using jboss serialization instead of the regular java serialization.
In short we changed the ObjectOutputStreams in the JavaObjectStreamFactory class to use JBossObjectOutputStreams instead (and input of course).
Now, we cannot be 100% sure that we gained cpu by doing this. It is possible that the hot spot just got spread out over multiple methods so the hot spot disappeared but we lost cycles over all. But the hot spot was removed from the list nevertheless.
So my question is, is there a reason why jboss cache is not using jboss serializing for serializing objects? Since jboss serializing takes pride in being x times faster then vanilla java serializing, wouldn't this be a desirable element to include in the cache?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103744#4103744
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103744
18 years, 8 months