6

This is a similar problem to Forcing a transaction to rollback on validation error The scenario is this: A user edits a page, the transaction is set to MANUAL so only if we call flush it would be committed to the database. Now the user wants to cancel the changes. Easy as you haven't flushed it yet.

Now consider this scenario: User edits page with lots of ajax on there. Some of these ajax callbacks require database queries (e.g. using a richFaces suggestion box etc). Some validation is done as well that requires database lookups. The problem is Hibernate will automatically issue a flush when you do a query. So the user doesn't press the save button (which would flush the transaction) he presses the cancel button. What do you do now?

If you don't do anything the changes will be written to the database - not what the user expects.

You can throw an exception that is annotated with 

@ApplicationException(rollback=true)

That would rollback the transaction. You can then redirect to another page. However here I've come across another problem, on some pages you redirect to you get a lazy initialisation exception. I've specified 

<exception class="com.mycomp.BookingCancelException">
    <end-conversation before-redirect="true"/>  
    <redirect view-id="/secure/Bookings.xhtml">
        <message severity="INFO">#{messages['cancel.rollback']}</message>
    </redirect>
</exception>

in pages.xml, so the conversation should end before we are doing the redirect. A new conversation should start (with a new transaction) but that doesn't seem to happen in all cases? Why?

I've read somewhere else that you can simply use

Transaction.instance().rollback();

This would be preferable as you don't have to go via exceptions (the redirect always takes long when Seam handles exceptions) but the problem is that the Transaction isn't actually rolled back. I couldn't figure out why. If I check the status of the transaction it says that it is not in rollback state.

How would you best handle Cancel requests. The pure MANUAL flush doesn't work in this case. You could work with detached entities but the page contains several linked entities so this is getting messy.

Update: I've now discovered that throwing the ApplicationException doesn't rollback the transaction in all cases. So rather confused now.

Update 2: Of course rolling back transactions will not work when you have an page where you use ajax to update values. Each transaction only covers one request. So if you do e.g. 5 edits with ajax request, rolling back a transaction will only roll back the changes from the last ajax request and not from the earlier 4 ones.

So solution is really to use the flush mode MANUAL.

There are a few things that will cause a flush even if you specify MANUAL.

  • a query in an ajax request can trigger a flush - Use setFlushMode(FlushMode.COMMIT) on the query to avoid this.
  • Persisting an entity can trigger a flush depending on the ID generation used (e.g. if you use the strategy IDENTITY). You can work around this by using Cascades. If you need to create entities during the edit which don't have any real relationship with the main entity your are editing just add them to a list and persist all entities in that list when you do a save.
  • When you start a nested conversation or another bean joins the conversation the Flush Mode on that session is set back to AUTO when you don't specify @Begin(join=true,flushMode=FlushModeType.MANUAL)

You might want to specify MANUAL as the default mode in components.xml

<core:manager concurrent-request-timeout="10000"
  conversation-id-parameter="cid" conversation-timeout="600000" default-flush-mode="MANUAL"/>
Community
  • 1
  • 1
Ben
  • 1,922
  • 3
  • 23
  • 37

3 Answers3

0

You can manage your transaction and manage it with the button activated.

    protected void doGet(HttpServletRequest request,
                         HttpServletResponse response, String butonPressed)
            throws ServletException, IOException {

        try {
            // Begin unit of work
            HibernateUtil.getSessionFactory()
                    .getCurrentSession().beginTransaction();

        } catch (Exception ex) {
            HibernateUtil.getSessionFactory()
                    .getCurrentSession().getTransaction().rollback();
            throw new ServletException(ex);
        }
        finally
        {
            if ("SAVE".equals(butonPressed))
            {

            // Process request and render page...

            // End unit of work
            HibernateUtil.getSessionFactory()
                    .getCurrentSession().getTransaction().commit();
            }
            else
            {
                HibernateUtil.getSessionFactory()
                        .getCurrentSession().getTransaction().rollback();
            }
        }

    }
Rija Ramampiandra
  • 231
  • 3
  • 4
0

Have you tried 

@Begin(flushMode=MANUAL)
someRandomValidationMethodHere(){ ... }

or setting 

<core:manager conversation-timeout="120000" default-flush-mode="manual" />

in components.xml?

gebuh
  • 797
  • 14
  • 40
  • I am already using manual flush mode. The problem is that hibernate will automatically do a flush if it things it needs to e.g. Normally when you do a database query. So by that point you cannot simply leave the conversation to cancel everything. – Ben Mar 10 '12 at 08:59
  • How about changing hibernate flushMode? If hibernate flushMode is set to AUTO or ALWAYS it will flush the data whenever a query runs. If you change it to COMMIT won't flush the data without a commit ... or at least it should. It would be edifying to add some debug statements to output the current hibernate flushMode around your db calls for validation. – gebuh Mar 10 '12 at 23:53
  • Do you know how to set your hibernate seesion? You can inject it or access it just like entityManager if you declare it in components.xml. Check out [this stack overflow question](http://stackoverflow.com/questions/3441145/help-me-to-understand-seam-and-hibernate), though I'm not sure about the cfg-resource-name stuff, I have to check my code, but I don't recall using that. – gebuh Mar 13 '12 at 02:28
  • You can get the Session from the (Session)entityManager.getDelegate() – Ben Mar 13 '12 at 08:22
0

It might be helpful to know that you can tell the ajax validation components not to flush, using the attribute bypassUpdates. Here's an article explaining it.

Óscar López
  • 232,561
  • 37
  • 312
  • 386
  • This still won't fix the problem where you do lookups (e.g. richfaces suggestion box) wouldn't it? – Ben Mar 12 '12 at 11:33
  • But lookups don't update the data model, and should not be done in a transaction anyway – Óscar López Mar 12 '12 at 14:18
  • @Ocars Lopez: Do you use Seam? Every database access is done in a transaction. Seam (if you use Seam managed transaction) or the EJB container will start it automatically for you whenever a bean is invoked from the web layer. If you use long running conversations this transaction covers the whole conversation. – Ben Mar 13 '12 at 08:20
  • @Ben that's partially true; you can annotate a method with `@Transactional(NEVER)` for excluding it from the context of any active transaction, a good practice for read-only search/query/lookup methods – Óscar López Mar 13 '12 at 13:38
  • Every database access is done in a transaction. From the book "Java Persistence with Hibernate" (section 10.3.1): "Many application developers think they can talk to a database outside of a transaction. This obviously isn’t possible; no SQL statement can be send to a database outside of a database transaction. The term nontransactional data access means there are no explicit transaction boundaries, no system transaction, and that the behavior of data access is that of the autocommit mode. It doesn’t mean no physical database transactions are involved." – Ben Mar 13 '12 at 18:02
  • Have a read here: http://forum.springsource.org/showthread.php?74937-Queries-outside-a-Transaction – Ben Mar 13 '12 at 18:04