Hi Java gurus, There is a lot of talks about declarative transactions out there. They are supported by EJBs, Spring etc. But are declarative transactions really good? My experience shows that this is something that needs to be avoided. I always want to know the boundaries of my transaction, and I always want to clearly see in my Java code where transactions start, where they commit and where they rollback. I stay away from relying on XML files that cannot be compiled, verified and can be changed manually after the code has been compiled. I would prefer my code to be clear about transactions, event though this might involve a little bit more coding. What do you think?
- Posted by: Sergei Batiuk
- Posted on: September 05 2006 17:33 EDT
Answer like for any interesting architectural question is: "It depends " -))... For some straight forward CRUD operations, i don't see a reason why not use declarative .... whereas for business methods accessing data from other datasources, some times 2 phase (distributed)...other integration techniques....to legacy ....etc., probably non declarative makes sense.... In my case, there was a scenario where drivers were not supported for XA transactions, we had to use bean managed transactions...and handle the compensating methods, state management, undo, redo...etc., Bhagvan K http://www.jroller.com/page/bhagvank