Re: Transactions when are they used

Here are some of the issues which I see with this:

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]]*On 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".