1. Using UserTransaction is the same thing as using J2EE transaction. It's just a difference of you starting the TX or the container doing it for you. 2. Using database transactions, ie accessing Connection.commit() and Connection.rollback() is against J2EE spec, it might work for one server but not for the other 3. You can forget about using Entity beans, they require J2EE TX for any reasonable performance 4. You should perform some testing to see if starting J2EE tx is that much faster before commiting to breaking the J2EE spec.
-- -AP_ http://www.myprofiles.com/member/profile/apara_personal http://www.myprofiles.com/member/profile/apara_business
Bimalesh Jha wrote:
Hi, My views on this: If the transaction is part of your workflow, then it is good idea to have it in your 'middleware' (EJBs). Your application can cater to multiple clients (Web, Mobile, XML/SOAP etc) + use loose coupling (using complementary technologies like JMS, MOM, Web Services etc) to backend database.
Handling transactions at the database, will probably, aid in performance, but, make the application less portable (across different databases) and also, you may not be able to integrate with different front-ends easily. Having database centric transactions induces single point of failure and application may not scale up very well.
If your transactions are 'short', it would be a better idea to encapsulate it inside your middleware.
Regds, BJ
-----Original Message----- *From:* vikramjit singh [mailto:[EMAIL PROTECTED] *Sent:* Monday, October 13, 2003 10:16 AM *To:* [EMAIL PROTECTED] *Subject:* Re: Transactions when are they used
Your architect is right, handling transactions in the database has much better performance than compared to using J2EE transactions. There are many scenarios where J2EE transaction is used. In our project we have used UserTransaction, since the data which the user is entering is critical, and the logic for inserting the data is written in the Session beans, and the data is inserted into database via Entity beans i.e. CMP. The data as has to be ATOMIC, having transactions in the Middleware is more suitable. If your database is fixed.. its not gonna change, then its much better performance wise to put the logic and transaction handling in the database.
vikram.
-----Original Message----- *From:* A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED] Behalf Of *Ranjit Gopalan *Sent:* Saturday, October 11, 2003 10:20 PM *To:* [EMAIL PROTECTED] *Subject:* Transactions when are they used
The architect for one of our project opted for database transactions instead of EJB transactions. The reasons given for this are
1. Performance 2. Single datasource.
So what is the design requirment to start using middle ware transactions other than multiple datasources.
A follow up of the question
Are really transactions used in J2EE project?. I found not a lot of projects have used EJB transactions when i did a g search and had discussion with my friends. Am i correct to assume this.
Thanks
Ranjit
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
