Hi!
Do you know how to handle this situation?
Do you use the Hibernate Persistence Context?
If, you could try to add a session.setFlushMode(FlushMode.MANUAL) which
should avoid any unwanted flush ...
Back buttons are really nasty. Very nasty. So any solution to problems with
back-buttons is also likely to be nasty.
Yep - back buttons have some "nastiness". One thing you definitely have
to ensure is that you send the hhtp infos to disable the browser cache.
At least then the user will always see actual informations.
Then you'll still have a problem with back when it goes back to a form
which issued an action, then this action will be issued again. This is
something a form token can prevent I think.
Still, Martin Marinschek already asked me to implement an enhancement to
the @ConversationRequire stuff which checks not only if a conversation
is active but also if it is the conversation required for a given view.
Means, we have to put a list of all conversation identifier (simply the
System.identityHashCode(conversation)) as attribute to the viewRoot in
the afterResponse phase and then check against them.
For the back button this simply means, if a conversation has ended - and
even restarted - and you press the back button, you'll be redirected to
the entry page again.
This might also render the form token useless, though, not sure ...
One thing I'm puzzled about is why executing a query would "flush" the context,
let alone commit the transaction. You're not calling flush or commit in your code at all?
Depending on the flushMode you configured Hibernate it WILL flush if you
query a table where dirty entities are queued to be sent to the DB.
Ciao,
Mario
