I really have no idea, but my suspicion is that because Derby is an in-JVM DB, it somehow ties together the JVM thread and the DB connection. When you start doing multithreaded stuff that one-to-one association is no longer valid, and things go south. That's pure supposition, however, and quite likely is actually an issue with the CFML engine not using ThreadGroups correctly rather than with Derby.

However if I use thread.txn = ormGetSession().beginTransaction() where a separate thread is used to processes data in the background it works fine in MySQL by Derby cannot handle any requests until the thread processing is complete. It gives error like this: java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested.

Its not a problem for my apps – just curious why Derby chokes.

The initial CF9 release is broken regarding the way sessions are handled across transaction boundaries. The issue has been resolved by the CF team at Adobe. I would imagine a change of this magnitude would NOT come out as part of a hotfix, but only as a point release, so I'd be surprised if we see it before the official 9.0.1 drop. I have no information about when that might be.

Does that mean in CF9 with latest HotFix/update (or next HF) we can use the CF transaction function and not ormGetSession().beginTransaction() or is it fixed in a yet to be released HF/update?

Thanks

It depends. In this simple example it'll be safe, because creating the new object and calling the setters doesn't require any DB interaction (which would happen outside a transaction). The point is that you have your transaction demarcation in the right spot, just as if you were writing SQL manually. You never do this (read outside a transaction in order to write inside a transaction) with SQL:

set @x = (select ... from somehwhere ...)
begin transaction
update something set col = @x
commit transaction

The same principle applies with ORM, just it's far more difficult to determine when the data access is happening when you're not in control of the raw SQL. Typically this sort of thing would crop up with defining relationships, but could also be caused by lazy loading across a multi-table entity, certain primary key generators, etc.

a = new com.site.Account();
a.setName(attributes.name);
a.setUsername(attributes.username);
a.setPassword(attributes.password);

txn = ormGetSession().beginTransaction();
try {
  entitySave(a);
  txn.commit();
} catch (e) {
  txn.rollback();
  throw e;
}

If this is valid then it makes life a lot easier!

Thanks!

- John

If you're using raw Hibernate, the read-only transaction is a fantastic tool for ensuring you don't shoot yourself in the foot (and that no one else does either). Unfortunately it's not available to us in CF, at least that I'm aware of.

It's not really about minimizing damage, though. At least in my mind, it's more about failing fast when you create a bug (in this case a non-transactional write). I don't want to protect my database when it happens in production, I want to ensure that the developer gets yelled at when it happens in development so the broken code won't ever make it to SVN. Which isn't to say the in-production benefits aren't nice (they're hella nice), but a hard fail at develop time is a huge win.