I am, sort of. You really can't leave the transaction open beyond the request response as it may never complete.
Some of the ways you can deal with it are: 1) work with fake holder entities that get changed back into real entities at the final commit. Very ugly -- tried this one at first, but I don't use it anymore. 2) Work with detached objects. Reattach them back right before the final commit. This is what I currently do. I basically invented a Unit-Of-Work framework that runs over the top of JPA. The unit of work has a separate persistence manager that loads an object, then immediately detaches it. Our framework requires each object to call save() to commit changes. When in the UoW, all save does is add the object to a change-tracker (inserts, deletes, updates). Then when the UoW is committed, the objects are persisted or merged, then committed all in one method call. But in all honesty, this approach also has caused us a lot of hassles. We are most likely going to dump JPA and replace it with Apache Cayenne, which uses a real unit of work concept. Another option for you might be to use an implementation-specific unit of work provided by your JPA implementation. However, I don't know if you might have other issues. I used Cayenne before I used JPA, and I know Cayenne does exactly what I need. A third option you could consider if you want to risk leaving the transaction open. a) Catch the window onunload event, and mixed with ajax, send an ajax request when the user improperly attempts to leave the page (closes the window or browser, enters a url directly, back buttons, some other non-transaction-friendly link clicked). I got this far with that approach, but didn't pursue it. Note that this can only detect when the user is about to leave the page. It cannot do anything at that point -- you'd have to do something about it in some other way. window.onbeforeunload = confirmExit; function confirmExit() { if (needToConfirm) return "You have attempted to leave this page. If you have made any changes to the fields without clicking the Save button, your changes will be lost. Are you sure you want to exit this page?"; } b) Some other kind of client-side state tracking so that you know when the user has navigated away from the current multi-request task. We're sticking a taskGroupIdentifier field on every form (ajax included) so we know when the user does something to switch to a new task than the one we're currently working with. Doesn't help if you have some transaction left open and the user never hits the web server again, but a timeout could deal with that. In short, I think it's a difficult problem, and I think JPA is incapable of dealing with it correctly. The other shortfall we have is that JPA cannot rollback a transaction. You have no way of knowing what state your application is in once you roll back the transaction. Again Cayenne automatically puts everything exactly where it was at the start of your unit of work if you do a rollback. On Thu, Jul 1, 2010 at 9:53 AM, Bruno Aranda <brunoara...@gmail.com> wrote: > Hi, > > Is anyone here using long JPA transactions in their applications > (transactions that span more than one request) but not using Orchestra?. How > are you doing it? > > Cheers, > > Bruno >