 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2006which transaction to be used ?
hi, whats wrong with JDBC transaction ? JDBC transaction has commit(), rollback() .......etc.....then why people will use JTA transaction ? i am confused when i should use JDBC transaction and when JTA transaction. do you think , JDBC transaction is error-prone and so JTA has been invented ? please let me know the difference between these two and let me know where i should use JDBC transaction and where JTA transaction Thank you > whats wrong with JDBC transaction ? > [quoted text clipped - 11 lines] > and let me know where i should use JDBC transaction and where JTA > transaction JDBC transaction only works for one data source a transaction manager transaction can work for multiple data sources Arne > a transaction manager transaction can work for multiple data sources > > Arne Only if the driver is XA Compliant (Transaction Aware). -cheers, Manish Arne Vajh?j wrote: > > whats wrong with JDBC transaction ? > > [quoted text clipped - 13 lines] > > JDBC transaction only works for one data source do you mean ? we can not do the following in JDBC transaction ? DataSource ds1 =(DataSource) //JNDI look-up DataSource ds2 =(DataSource) //JNDI look-up DataSource ds3 =(DataSource) //JNDI look-up why ? whats wrong with this ? if i use WebSphere , i can set multiple datasources in it. and then i can call like above to get the data sources inside the code and then i'll use JDBC transaction....it can not be stopped. please explain what you meant ? > a transaction manager transaction can work for multiple data sources > > Arne >> JDBC transaction only works for one data source > [quoted text clipped - 13 lines] > and then i can call like above to get the data sources inside the code > and then i'll use JDBC transaction....it can not be stopped. You can certainly use multiple data sources. But because a JDBC transaction is on a per connection basis then you can not have them in the same transaction. Arne > >> JDBC transaction only works for one data source > > [quoted text clipped - 20 lines] > > Arne hi, this is not clear . could you please tell precisely, what cant be done for JDBC? DataSource ds1 =(DataSource)//jndi lookup Connection con=ds1.getConnection(); //transaction starts here //trans ends here Now, please tell...what cant be done here ? > hi, this is not clear . > [quoted text clipped - 8 lines] > > Now, please tell...what cant be done here ? If you perform an operation that need access to several *independent* databases and that operation as a whole must be transactional, then the jdbc transaction can not help you. A jdbc transaction only works within *one* database at a time. Consider this example: You are building web interface for a stock exchange sales system. The stock exchange already has a stock sales system, and a customer account system, which are independent of each other, because of regulatory, security and stability reasons. Now you want to add a web interface to this. For obvious reasons you can not add this to the existing systems, so you have to build a new system running independently of the others. For the system to be able to perform its sales operations through the web interface, it needs access to both the customer account system and the stock sales system with system wide atomicity. That means that if the sale fails in one of the two subsystems it will fail in all. This is because you don't want to be charged for stocks you never received, and the other part does not want to give you stocks for which you don't have the money for) This is why we have JTA. JTA also supports a wider sense of resources in j2ee, not just database transactions, for example between different ejb beans in different containers/machines etc. Hope this clears things up for you. tom > > hi, this is not clear . > > [quoted text clipped - 13 lines] > jdbc transaction can not help you. A jdbc transaction only works within > *one* database at a time. I am allowed to do this .... class.forName(oracle_driver) //get connection class.forName(sybase_driver) //get connection // and do the JDBC transaction with proper exception handling This is offered by JDBC. you really can access several distributed DB via JDBC .....oh,yes ...if you say , you need to do some CLEVER exception handling for a perfect atomic transaction ,yea....then JDBC would be a messy thing i suppose....BUT nothing stops to do it ........so, i cant say,"it cant be done" ..........is not it ? it can be done but it would be tedious .....right ? still, i dont understand a concrete difference what JTA can do but JDBC *cant* do. so can i assume JTA is a suprior API because it offers more flexibilty and there is no such big difference between JDBC trans and JTA trans .......JTA offers ease and comfortability. i doubt this conclusion though....there must be some difference > Consider this example: > [quoted text clipped - 19 lines] > > tom > I am allowed to do this .... > [quoted text clipped - 14 lines] > be done" ..........is not it ? it can be done but it would be tedious > .....right ? messy thing = requiring JTA Arne > still, i dont understand a concrete difference what JTA can do but > JDBC *cant* do. > so can i assume JTA is a suprior API because it offers more flexibilty > and there is no such big difference between JDBC trans and JTA trans > .......JTA offers ease and comfortability. JDBC transactions are atomic within a single connection. JTA transactions are atomic across multiple connections. You can't achieve this using JDBC transactions; you need deeper coordination between the different connections (underlying DBMSs), otherwise it won't be a 'distributed' transaction.  SignatureLee Fesperman, FFE Software, Inc. (http://www.firstsql.com) ============================================================== * The Ultimate DBMS is here! * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com) >> still, i dont understand a concrete difference what JTA can do but >> JDBC *cant* do. [quoted text clipped - 6 lines] > deeper coordination between the different connections (underlying DBMSs), otherwise it > won't be a 'distributed' transaction. You can use JDBCs XAConnections to get distributed transactions in a set of databases, but it only works with databases. jta works with other resources as well. (disclaimer: I havent used XAConnection so I dont know the practicalities and its drawbacks) tom > You can use JDBCs XAConnections to get distributed transactions in a set > of databases, but it only works with databases. jta works with other > resources as well. (disclaimer: I havent used XAConnection so I dont > know the practicalities and its drawbacks) Even with XAConnection, you need an implementation of something like JTA to coordinate transactions for the distributed resources. XAConnection is database oriented, however the newer JCA supports both DBMSs and other, non-DBMS resources for distributed transactions. See my JDJ article -- "Understanding JCA" (http://sys-con.com/story/?storyid=46283&de=1). SignatureLee Fesperman, FFE Software, Inc. (http://www.firstsql.com) ============================================================== * The Ultimate DBMS is here! * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com) > still, i dont understand a concrete difference what JTA can do but > JDBC *cant* do. [quoted text clipped - 3 lines] > > i doubt this conclusion though....there must be some difference Did you read my entire reply? JTA is concerned with more than just databases, it is concerned with resources. So any resource in a system that is supported by the local transaction manager and jta can be part of a transactional context. jta transactions start at the app level not the dba level, so objects, beans etc can be part of the transaction and the scope is determined at the app level. Database wise JTA just makes it a lot simpler to use distributed transactions, just because all the plumping code is already done for you. And that is a lot of the point in j2ee, that the plumbing code and support code (libraries, apis etc) is pre-done by someone else, so you dont have to invent the wheel every single time. tom > > still, i dont understand a concrete difference what JTA can do but > > JDBC *cant* do. [quoted text clipped - 18 lines] > > tom >From your reply, i can see that you are giving more importance on use of *resources* rather than just DB only and is offered by JTA only. well, whats those resources ? you have mentioned , objects , bean , etc can be part of a transaction .......wow , is it ? how it works ? and for what purpose ? whatever the example i have seen for the JTA , it deals with DB level , couple of insert , update tec . How other resouces e.g bean , objects are used in JTA ? can you please provide some example How other resoures are handled by JTA ? and whats the purpose of that ? thanks > well, whats those resources ? you have mentioned , objects , bean , > etc can be part of a transaction .......wow , is it ? how it works ? > and for what purpose ? What purpose do you think its for? search the net, read a couple of articles with different view points on the subject and think about it > whatever the example i have seen for the JTA , it deals with DB level , > couple of insert , update tec . Yes, because its easiest to show thing with standard examples. F.ex how many times have you read about foo() and bar() examples. How many times have you read an Hello World example. But also because transactions and systems often involve databases. > How other resouces e.g bean , objects are used in JTA ? Did you read my example scenario in one of my previous posts in this thread? > can you please provide some example How other resoures are handled by > JTA ? and whats the purpose of that ? Google is your friend... here is at least one article about jta (perhaps not the best one to illustrate what I am saying, but it does help) http://www.onjava.com/pub/a/onjava/2001/05/23/j2ee.html tom >>>> JDBC transaction only works for one data source >>> do you mean ? [quoted text clipped - 16 lines] >> But because a JDBC transaction is on a per connection basis >> then you can not have them in the same transaction. > hi, this is not clear . > [quoted text clipped - 8 lines] > > Now, please tell...what cant be done here ? Nothing. But there are only one datasource. Arne Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.