Does EJB 2.x (heck, even JDBC) acknowledge the existence of nested transactions (of course assuming the DB supports 'em).
Our use case would be creating a user, given a unique constraint on their usernames. Would like to attempt to create the user entity within a subtransaction, so that if the proposed username is already in use as dictated by the database, then the subtransaction could be aborted (since it is now hosed due to violating a unique constraint). The driving code in the outer transaction could then back up and retry using a different (autogenerated) username.
Doing the user creation in a RequiresNew SLSB method won't do because if the original transaction rolls back, we certainly don't want the user to remain in there.
Currently we've implemented via a findByName call, followed by a create if the finder fails. Of course that's a race condition though. I guess we could code the automatic username generation user creation ultimately as a stored procedure, but that seems ugly.
With PostgreSQL about to support nested transactions, just wondering if we lowly EJB app developers are allowed to get that close to the metal. Sad when SQL is considered close to the metal.
There is nothing wrong with using JDBC and SQL within an EJB.
Entity beans (and any Object-to-Relational-Mapping tool for that matter) are meant to make the common CRUD database operations easier. Anytime you need to do something strange or performance-intensive, you can fall back to JDBC/SQL or even stored procedures.
I have an idea.My genuine question for u is do u really need a nested database operation?I don't think so.With help of primary key concept(a variable/or a class), you can immediately throw exception in case u r trying to insert a row with same primary key that is, USER_ID. So, my sugestion is, if it throws exception, then again create another id(don't know how do u create) user id and get it insreted inside EXCEPTION BLOCK of code.
Please reply if it suits u.
Can't do that, Pratap, because the JDBC connection is hosed until the current transaction rolls back. We have primary key constraint on the username. If the exception block then tries a different name, it fails with the database backend complaining that the only thing that can be done with this transaction is rollback. Which is why they're implementing nested transactions in the postgres backend.
Ended up not attempting to use auto-generated usernames. Just too ugly code-wise, and didn't generate usernames that the users were going to be happy with anyway.