I want to use teradata data source in global transaction in websphere 9.0 along with oracle XA datasource.
I am trying to figure out how to setup teradata as XA datasource, is there specific implementation class similar to oracleConnectionpooldatasource vs oracleXAdatasource? Do we have an equivalent XA datasource implemenation for TeraConnectionPoolDataSource? Is there connection pool property we can set?
Thanks
The Teradata JDBC Driver Reference documents only TeraConnectionPoolDataSource (which implements javax.sql.ConnectionPoolDataSource) and TeraDataSource (which implements javax.sql.DataSource). This leads me to believe that they do not provide an implementation of javax.sql.XADataSource.
That said, it is possible in WebSphere Application Server, at the cost of certain trade-offs, to have a data source which doesn't implement javax.sql.XADataSource participate in a global transaction alongside two-phase commit capable resources (such as the Oracle XADataSource). To do this, you must be willing to accept the possibility that if an outage or other interruption occurs after the point where the two-phase resources have completed the prepare phase when the one-phase resource (TeraData in this case) is told to commit/roll back, then the transaction manager will not know the outcome of the one-phase resource, and will be unable to automatically determine the outcome during XA recovery, such that resolution of the transaction will require manual intervention. This capability is often referred to as "Last Participant Support" (due to placement of the one-phase resource as the last resource after all of the all of the two-phase resources complete the prepare phase), and is also referred to as "Accept Heuristic Hazard" (due to the situation described earlier in this response where there is uncertain outcome).
Related
I am using Oracle and Teradata both databases in my Java based project. I want to setup global transaction so that I can perform operations on both the Database under one transaction.
For global transactions such as JTA or atomikos database must have XA driver support. But as my findings Teradata doesn't have XA driver.
So now how could I setup the global transaction and performance operations on both database under 1 transaction?
why would you want to do that?
If you use terradata as a data warehouse, you could feed it in a separate, asynchronous process.
That being said, you don't strictly need an XA driver to run as part of a JTA transaction. Of course, not doing so leads you to make some compromise, especially in case of recovery.
All JTA-aware transaction managers I know have the notion of Last Resource Commit (or LRC, check this page for more details). You could configure your Teradata datasource as LRC.
Resources
Bitronix config
Atomikos config
If you use oracle and the teradata database, you need to configure the oracle database gateway to support distributed transactions. In that you will not use XA, but you will use distributed transactions with two-phase commit.
hi,
If two resources are involved in a transaction then the XA transation
setting should be enabled in the weblogic server. Then the xa drivers
has to be chosed.Is there a alternative way to have this two
resources in a transaction without enabling XA transaction
Yes, you can use Global Transaction Emulation. WebLogic has two mode:
Logging Last Resource - WebLogic creates a table into all your datasources and write transactions data into this table. This is a preference option.
From official documentation:
With this option, the transaction branch in which the connection is used is processed as the >last resource in the transaction and is processed as a local transaction. Commit records for >two-phase commit (2PC) transactions are inserted in a table on the resource itself, and the >result determines the success or failure of the prepare phase of the global transaction. >This option offers some performance benefits and greater data safety than Emulate Two-Phase >Commit, but it has some limitations.
see http://docs.oracle.com/cd/E15051_01/wls/docs103/jta/llr.html
Emulate Two-Phase Commit - transaction branch always return "SUCCESS" while prepare phase. Select this option if your app can tolerant heuristic conditions.
see http://docs.oracle.com/cd/E23943_01/web.1111/e13737/transactions.htm for more information.
I prefer LLR option, but if you work with legacy DB and do not have the table create grant, you should use two-phase commit emulation.
I have a an appliction running on the WebSphere application server (7.0.0.19), using DB2 database (9.5). I have the impression that the application server or the database ignores the isolation level which is set in the application (in the Java code). The application uses gets the connections from the application server, it uses the transaction manager from the application server.
I did not find a clear answer (or acknowledgement), not in the manuals, not on the web. I found some indications, suggestions, insinuations, but no clear answers. Some monitoring on the database seams to prove this.
Can someone acknowledge this behaviour?
Can this be changed using configuration?
Since the data source is managed by the application server (and WebSphere is a full featured implementation of Java EE), it's actually the JCA spec that applies here. Section 7.9 of the JCA 1.5 imposes the following restrictions on the ability of an application to change the transaction isolation level:
If a connection is marked as shareable, it must be transparent to the application whether a single shared connection is used or not. The application must not make assumptions about a single shared connection being used, and hence must use the connection in a shareable manner.
However, a J2EE application component that intends to use a connection in an unshareable way must leave a deployment hint to that effect, which will prevent the connection from being shared by the container. Examples of unshareable usage of a connection include changing the security attributes, isolation levels, character settings, and localization configuration.
To summarize: in general, your application should not attempt to change the isolation level if the resource reference configures the connection as shareable. If you look at the Requirements for setting data access isolation levels topic in the WAS infocenter, you will also find the following statement:
Trying to directly set the isolation level through the setTransactionIsolation() method on a shareable connection that runs in a global transaction is not allowed. To use a different isolation level on connections, you must provide a different resource reference.
On the other hand, section 7.9.1 of the JCA 1.5 spec describes scenarios where an app server may still allow an application to change the isolation level, even if the connection is shareable. Basically this applies to scenarios where the connection is configured as shareable, but where it is effectively not shared (because there is no need to share the connection between multiple components).
The Extensions to data access APIs topic in the infocenter suggests that WebSphere supports this:
applications [...] cannot modify the properties of a shareable connection after making the connection request, if other handles exist for that connection. (If no other handles are associated with the connection, then the connection properties can be altered.)
Therefore you should be able to use setTransactionIsolation() to change the isolation level in particular scenarios, but this depends on how your application uses the connection.
Finally, you didn't describe in detail how you monitored that at the database level, but you need to take into account that at some point the app server needs to reset the isolation level on the physical connection. Therefore, if setTransactionIsolation() succeeds, the change may be in effect only for a short time on the physical connection.
Note that there are a couple of ways to avoid all these complications (that may or may not be applicable in your case):
Instead of using setTransactionIsolation(), configure the appropriate isolation level on the resource reference, and if necessary use multiple resource references.
Use the WebSphere specific WSDataSource API to specify the expected isolation level before acquiring the connection.
Modify your SQL to change the isolation level on a per query basis (e.g. use WITH UR).
http://www.ibm.com/developerworks/java/library/j-isolation/index.html this is relevant
also ejb transactions and isolation level discussion applies
http://java.boot.by/ibm-287/ch05.html
I wan to know how the transaction is internally implemented in EJB. I want to know the logic they use to create a transaction. if you could point out some articles that would be helpful
Hibernate doesn't implement transactions, it relies on and wraps JDBC transactions or JTA transactions (either container managed or application managed).
Regarding EJBs, if you want to understand the details of a JTA Transaction Manager, you'll need to be fluent with the JTA interfaces UserTransaction, TransactionManager, and XAResource which are described in the JTA specification. The JDBC API Tutorial and Reference, Third Edition will also be useful to understand the XA part of a JDBC driver.
Then, get the sources of an EJB container (like JBoss) or of a standalone JTA Transaction Manager (like Atomikos) to analyze the TM part. And good luck.
This question could have answers at many levels.
A general discussion of what's going on can be found here
My summary goes like this ... First, somewhere there must be a transaction coordinator, the EJB container will know about the coordinator - typically that's part of the application server. So all the EJB container has to do is to call
someobject.BeginTransaction()
that's it. The actual API the EJB container uses is JTA. EJBs can actually use Bean Managed transaction transaction or Container managed transactions. In the Bean Managed case the implementer nhas to make the JTA calls. More usually we use Container Managed transactions (CMT). In which case the container has logic which is run before the implementation is reached. For example:
if ( we're not already in a transaction )
begin transaction
call the EJB implementation
and later the container has logic
if ( finished processing request )
commit transaction
with other paths to abort the transaction if errors have happened.
Now that logic is more complex because CMT EJBs are annotated with transaction control statements. For example you can say things "if we already have a transaction, use it" So if one EJB calls another only a single transaction is used. Read up the EJB spec for that.
However all that's pretty obvious in any write-up of Java EE EJBs. So I suspect that you're asking moe about what happens inside the JTA calls, how the transaction manager is implemented and its relationship to the transactional resource managers (eg. Databases). That's a huge topic. You've actually go implementations of the XA distributed transaction protocol down there. Frankly I doubt that you really need to need to know this. At some point you have trust the APIs you're using. However there is one key detail: your Transaction Manager (typically the App Server itself) must be able to tell the REsource Managers the fate of any given transaction, and that information must survive restart of the App Server, hence some persistent store of transaction information must be kept. You will find transaction logs somewhere, and in setting up the App Server you need to make sure those logs are well looked after.
From EJB in Action book
The protocol commonly used to achieve multiple resource is the two-phase commit. The two-phase commit protocol performs an additional preparatory step before the final commit. Each resource manager involved is asked if the current transaction can be successfully committed. If any of the resource managers indicate that the transaction cannot be committed if attempted, the entire transaction is abandoned (rolled back). Otherwise, the transaction is allowed to proceed and all resource managers are asked to commit.
A resource manager can be a database, for instance. Others examples includes a Message Service. The component which coordinates transactions is called Transaction manager.
Suppose you have an application which involves two distincts databases. How does Transaction manager performs its work by using Two phase commit protocol ?
Transaction Manager ask database 1 if it can commit the current transaction
If so, ask database 2 if it can commit the current transaction
Transaction Manager ask database 1 to commit
Transaction Manager ask database 2 to commit
Hibernate is built on top of the JDBC API. It just coordinates one database. So if you call
session.commit();
Behind the scenes, it call
connection.commit();
If you really want to study Transaction internals, my advice is Java Transaction Processing book.
Hibernate has TransactionFactory:
An abstract factory for Transaction instances. Concrete implementations are specified by hibernate.transaction.factory_class.
It has implementations: JDBCTransactionFactory, JTATransactionFactory, CMTTransactionFactory. These factories create an instance of Transaction - for example JDBCTransaction.
Then I can't tell you what happens for JTA and CMT, but for JDBC it's as simple as setting the auto-commit to false (when you call begin a transaction):
connection.setAutoCommit(false);
And respectively on transaction.commit(): connection.commit()
If any exception occurs when operating with the session, it invokes connection.rollback()
Another good read would be the JTS articles by Brian Goetz; links:
http://www.ibm.com/developerworks/java/library/j-jtp0305.html
http://www.ibm.com/developerworks/java/library/j-jtp0410/index.html
http://www.ibm.com/developerworks/java/library/j-jtp0514.html
I have two level access to database: the first with Hibernate, the second with JDBC. The JDBC level work with nontransactional tables (I use MyISAM for speed). I want make both levels works within transaction. I read about JTA which can manage distributed transactions. But there is lack information in the internet about how to implement and use custom resource.
Does any one have experience with using custom XAResources?
I want make both levels works within transaction.
Then you'll have to change your storage engine for InnoDB, MyISAM tables do not support transactions (technically, you won't get an error but a rollback won't rollback anything).
Does any one have experience with using custom XAResources?
I'm not sure to understand what you're talking about. The only XA resource I see here is your database and you don't need to implement anything custom. What you need to do is to use XA connections very likely obtained from two XA DataSources (which are supported by MySQL Connector/J 5.0.0+), use the JTA API and let the Transaction Manager do its job .
But to be honest, you should really clarify your requirements. There might be other (and easier) options than using XA. And if all the above sounds like Chinese, then I have the feeling that don't use XA would be a good advice here.
Connection are obtained via a DataSource that can be configured to support distributed transaction or not. To use multiple connections in a distributed transaction, you must configure the multiple DataSource to support XA and return XA connections.
That said, you need several physical connections only if you connects to different database, which doesn't seem to be your case (that's not clear in the question).
A DataSource can be smart enough to make sure that the same physical connection is used as long as you are in the same thread; each time you ask for a connection, it actually returns a "handle" to the same physical connection, and the physical connection returns to the pool when all handles have been closed. (But that depends on the DataSource implementation).
Hibernate per se is not an XA resource: it uses underlying a connection obtained via a DataSource. But it hooks itself in the transaction manager via JTA, in particular to flush all pending changes before the distributed transaction commits.
You can most of the time obtain the underlying connection used by the EntityManager using implementation specific API (it's at least possible with Hibernate). This means that you can maybe fulfill your requirement without using JTA and XA at all: use the underlying connection of the EntityManager for your JDBC stuffs.
In summary:
No need to mess with XAResource
Switch to InnoDB
You can try to switch to a XA DataSource and obtain a connection with DataSource.getConnection()
You can try to switch to a XA DataSource and obtain the underlying EntityManager connection
You can try to stick with a non-XA DataSource and obtain the underlying EntityManager connection
Hope I understood your question right and that it helps.