[Forgot to post this yesterday...]
steve wrote:
Check CVS. This will be in 3.0.1
Indeed, the code in the CVS head - without my patch - handles my scenario when using auto_close_session.
steve wrote:
BTW, you realize this is dangerous right?
If a session flushes in one of the "not the final" transactions, you've just lost atomicty of the overall transaction (a session is intended as a *transactional* thing).
Depends on what you mean by "dangerous". If I have multiple transactions within a request/Session, I want each transaction to be ACID, though I do not care about the atomicity of the request/Session. I.e. if I have two transactions and an exception is thrown halfway within the second one, surely I still want the changes made by the first one to be persisted. (If I would not, I would use a single transaction!)
Here are some example use-cases you might want to consider when thinking about whether discussed changes makes sense:
In several places in our system, we want to update a log table outside the JTA transaction, so that there will be a log record both for sucessfull and failing updates. That is:
Code:
[Create log record]
try {
userTransaction.begin();
[Try to perform update]
userTransaction.commit();
[Mark log record as successful]
}
catch(Exception ex) {
userTransaction.rollback();
[Mark log record as failure]
throw ex;
}
finally {
[Update log record]
}
We also have a few scenarios where it would be handy (or at least the most straightforward) to have a Session span several JTA transactions; although none of them should be necessary. Here are two examples:
Example 1: Read data for multiple updates. If one update fails, continue with the next one.
Code:
[Read data for updates]
[Look in database for records to update]
for(Foo f: foos) {
try {
userTransaction.begin();
[Try to update f]
userTransaction.commit();
}
catch(Exception ex) {
userTransaction.rollback();
[Log error]
}
}
(Truth be told, the loop is actually a loop across multiple databases/schemas/catalogs/namespaces, where the same table would be updated in each database/schema/catalog/namespace. So to stay clear of caching issues, separate Session might be preferrable)
Example 2: Within a single request, perform one mandatory and one "voluntary" update
Code:
try {
userTransaction.begin();
[Perform mandatory update]
userTransaction.commit();
}
catch(Exception ex) {
userTransaction.rollback();
throw ex;
}
try {
userTransaction.begin();
[Perform "voluntary" update]
userTransaction.commit();
}
catch(Exception ex) {
userTransaction.rollback();
[Log error]
}
Login
FAQ
Search
