---- alberto gori <[EMAIL PROTECTED]> schrieb: > My use case is this: > > -welcome page displays a list of users, > -I can click on a user and enter in detail. > -in detail I can modify (add or remove items from the user) the entity. > -I can save entity and come back to welcome page (user list). > > I have a UserListBean as managed-bean, in conversation scope. It gets the > user list from the database, and should also save the user modifications. > > Problems is: > if I add an item to a user and I press back button on the browser my entity > remains dirty, but I didn't saved the user! When a query is performed (for > example when I render the welcome page) > Hibernate flushes the dirty objects to the database. Clearly I don't want > this behavior: if no "save button" has been pressed no modifications should > be sent to the database. > > Seems that I need a way to say flush only when I invalidate the > conversation, or when I call persist or flush manually. > > Do you know how to handle this situation?
I've been thinking about this today. Back buttons are really nasty. Very nasty. So any solution to problems with back-buttons is also likely to be nasty. Please note that everything I write below is just guessing/speculation. I should add "Maybe", "Possibly", "Perhaps", "I guess" liberally throughout the following text :-) Firstly, we need to clarify some terminology. "flush" means that an SQL command is sent to the database in the context of some transaction, and that the corresponding entity in the persistence context is then no longer marked as dirty. A real database transaction can never be held open across requests, for obvious reasons. Therefore "flush" is something that must never be done except just before you really intend to commit the transaction. So I presume what you have at the start of the request triggered by the backbutton is an existing conversation with an associated persistence context which contains dirty objects, but no "flush" has ever occurred. Is that right? 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? Anyway, in normal page flow (no back button), it would be your "add item to user" page that would invoke some navigation action. And the java code (or jsf component) would then either explicitly allow the context to remain dirty, or commit it, or clear it, according to what you want. So the problem is just with the "back button" not allowing that page to take the appropriate action on exit. Ideally when the back-button-triggered request comes in the persistence context would be restored to what it held when the user was last on that query page, but that's (a) not easy, and (b) not implemented in Orchestra. I think that the best option for you at the moment is to detect back-button presses and then invalidate the conversation and redirect to the first page in this workflow. The persistence context will then be clear. Of course that means that "forward" will not work, but that's probably ok. There isn't anything in Orchestra to detect backbutton usage at the moment, but there are any number of existing solutions out there. I guess that in the medium term we should add some "back button" detection to Orchestra, just because it is so much more important when persistence contexts are hanging around. At the very least, clearing the context and redirecting to the workflow entry page, yes? As I noted on the WebFlow comparison page, it should be fairly easy to implement what WebFlow already does - the "Simple Continuation" anyway, for normal conversation beans. Not sure about the implications of saving persistence contexts though.. Opinions anyone? Cheers, Simon
