I don't know how the other O/R mapping technology, such as JDO or Hibernate, commits the changes into the database, but Toplink has an interesting behaviour when using the transaction from EJB container.
First, Toplink will remember all database updates (insert, update, and/or delete) being performed within a single transaction. Then, only after the method in which the transaction started exits, and when the EJB Container is about to close the transaction, Toplink will try to generate the SQL statements required to perform the above actions. Toplink then executes these SQL statements, in an order specific to Toplink's dependency algorithm which might differ from the order in which we instruct them to (within our code).
If and only if the database accepts all these changes, then Toplink updates its caches, and return the control back to the EJB Container which will successfully close down the transaction and return back the needed values to the client. If, for example, there's a database exception thrown during the commit phase, the catch block or any other code within our EJB code will not be invoked. Instead, the code of the EJB client will be the one who is supposed to handle the database-related exception.
Why? Because the exception were thrown after the EJB method completes, but before the EJB Container returns the control back to the EJB client. This is troublesome sometimes.
Well, I haven't learned much about Toplink nor any other O/R mapping technology, but is this the ideal approach?
I hardly believe it.. :D
Links:
Links:
Hibernate in Action
More Hibernate books
More JDO books
No comments:
Post a Comment