> However, if you leave a > transaction active after a response, it's > always going to be an issue no > matter what framework you use.
True for database connections, but not necessarily for JPA connections. At least not if you use optimistic locking, which is the default. Ofc if you use row locking, then the database connection needs to remain open. Reminds me of our old CICS applications where the whole compnany got a broadcast all 5 minutes: "who the hell is locking my customer sdlfsdf, damn I cannot edit it...". LieGrue, strub ----- Original Message ---- > From: Mike Kienenberger <mkien...@gmail.com> > To: MyFaces Discussion <users@myfaces.apache.org> > Sent: Fri, July 2, 2010 8:07:34 PM > Subject: Re: Long transactions > > I am not familiar with orchestra, so I can't comment there. It has not > been an option for us up to this point. However, if you leave a > transaction active after a response, it's always going to be an issue no > matter what framework you use. For us, the problem with holder objects is > the deep hierarchy of entities and relationships we have. We have > probably close to a thousand entities right now, and most > multiple-request-spanning transactions deal with very complex, deep, and > width relationship paths. They only work well in the simple cases > where we don't need them. On Fri, Jul 2, 2010 at 3:39 AM, Werner Punz > < > href="mailto:werner.p...@gmail.com";>werner.p...@gmail.com> wrote: > > Mike you left out the obvious one, simply use a conversation framework. > > The problem is not transactions but it is that the entity manger is > dropped > along the way hence silently detaching all objects and running > you into > detached error hell. (You still can either setup your jpa > provider so that > lazy loading can happen outside of transaction barriers > or prefetch > everything via fetch join) > > I personally > found as soon as you go to a conversation framework things > become way > easier (although not entirely easy) > > Also what was the problem > with holder objects. I personally am thinking of > moving that way > especially since JPA allows to map it transparently via > queries like > following select new FakeHolder( > href="http://entity.id";>entity.id, entity....) from > EntityClass > entity). > > The downside is that you need more logic for pushing > the data back into the > entity objects before writing. But the fake > holder pattern is exactly what > iBatis enforces (although it has the > write back logic pushed into the > configuration) and it works out well in > a web centric szenario. > > > WErner > > > > Am 01.07.10 23:54, schrieb Mike Kienenberger: >> >> 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< > href="mailto:brunoara...@gmail.com";>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 >>> >> > > >
