which transaction to be used ?

[gk]

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

JDBC transaction only works for one data source

a transaction manager transaction can work for multiple data sources

Arne

 

[Manish Pandit]

a transaction manager transaction can work for multiple data sources

Arne

Only if the driver is XA Compliant (Transaction Aware).

-cheers,
Manish

 

[gk]

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 ?

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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.

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

 

[gk]

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

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 ?

 

[Tom Forsmo]

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 ?

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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 ?

Nothing.

But there are only one datasource.

Arne

 

[gk]

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.

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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 ?

messy thing = requiring JTA

Arne

 

[Lee Fesperman]

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.

 

[Tom Forsmo]

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

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

 

[Tom Forsmo]

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.

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

 

[gk]

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

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

 

[Lee Fesperman]

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).

 

[Tom Forsmo]

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