>>- This is not a pessimistic transaction with WebLogic & Oracle >> >It is from the database perspective. Oracle doesn't actually support >optimistic locking, but a hybrid they call optimistic.
Well OK, maybe I was too brainwashed by Oracle. >>- A usual design pattern is to wrap handling of a use case behind a session facade which demarcates the transaction. >> >That's fine, but what's the use case the requires changing all artists >and their records in one transaction? The use case is the point of my >question. There is no specific use case related to this problem. I am not trying to get some specific case fixed, but trying to find some general guidelines / best practises that would minimize the problems related to the database deadlocks I mentioned. Now, before you say that there is no silver bullet / do not apply patterns blindly etc...there are always both good and bad practises with different problem areas. For example, with manual JDBC use you should close connections in finally block to prevent connection from being left open if an exception is thrown. That sort of things. To give you something concrete, maybe the example I mentioned earlier (user A views record r1 along with it's artist a1 while at the same time user B views artist a1's all records -> ORA-60) could be one, but as I mentioned it is just an example, not the beef here. Now, one could think about fiddling with transaction settings, maybe fetching data for record r1 could be done in a separate transaction to fetching data for corresponding artists A1. Maybe user would not care if a1 shows modifications by another transaction while r1 does not. Maybe that would be quite a rare condition. Or maybe that's not acceptable or wanted at all? The bottom line is that using (at least to me) very intuitive and common practises you still end up with concurrency problems using EJBs, even in this naive case. I was a bit surprised about this actually. And am curious, is this "expected" and normal behaviour, or should I have done something differently. And I am not buying into that I should have demarcated transactions somewhere else than the session facade, or that I should even have to spend lot of time thinking about transaction handling in such a simple case to get it "working". >Does your use case really require ACID qualities? Or is the use case >really a repetition of a another use case B? Use case B may need ACID >qualities even if the original use case doesn't. > >For instance, take generating invoices for recently shipped orders. The >use case would generate invoices for all recently shipped orders which >haven't yet been invoiced. This is essentially an iteration over a >generate invoice use case for a selected set of orders. Does it matter >to the original use case if invoice n fails? Probably enough to generate >an error message, but not enough to rollback all the successfully >created invoices. That's a good thing to remember, when you have certain use cases that would cause long transactions. >>Separate methods for each piece (negating the performance benefits of >>session facade)? >> >There's no significant loss of performance using Requires New. Deadlocks >are the ultimate in lost performance. Of course deadlocks are severe performance hit, but you cannot say that starting and committing n transactions would the same performance-wise as starting and committing 1? Besides, I was speculating about a situation where facade.getDataForArtistAndRecord() would be split to separate methods facade.getDataForArtist() facade.getDataForRecord() there's of course the added remote calls, which the session facade was meant to minimize (my original point). >>Handle transactions inside one method manually by JTA >>(lose the benefits of automatic transaction handling in EJB)? >> >How is automatic transaction handling being lost by adding explicit >demarcation? Calling setRollbackOnly explicitly isn't that hard. Yes, I would guess it's not that hard. Using EJBs brings a lot of added complexity to your project. For one entity you have to have several source classes, several deployment descriptors, more complexity to the deployment process, debugging etc. As you pay that price, you get something in return - you do not have to worry about transactions, security, distribution etc. as much. That's the whole point of EJB's. If you have to give up those benefits to get your project working I would whether using EJBs is worth the price that you have to pay. >Programming is all about trade offs. Following patterns blindly is never >a good idea. I agree. What was the part where I was following patterns blindly? =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
