Hi, I am a middleware consultant working in a bank and currently I am going to implement the EJB middleware components which will handle the 2-phase commit scenario. The infrastructure we are going to use will be based on IBM's new Websphere Application Server 4 and the Websphere Studio Application Developer 4. There are basically two remote databases the EJBs are going to talk to: the Oracle database and the SPAN database. For the Oracle DB we have to use the JDBC via the network remotely, for the SPAN db we have to use the AMI to interact with the MQ Series and do the connection via the queues. As in the above scenario, it is really a distributed transaction context. After reading your articles, I know that the J2EE container would provide the JTS transaction management behind the scene for the JDBC db and JMS message queue servers resources. However, I am not sure whether this feature would be valid to the our distributed environment mentioned as above: 1. for the JDBC remote connection, can the same transaction context management and roll back be still valid across the network, or can this transaction context be applied not just limit to the local environment? (ie: how the JTS would manage the following scenario: if there is a time out from the remote Oracle db due to the backend process is too busy in updating the db but still will fulfil the update finally, however at the same time the EJB treats it as a failure due to the timeout...) 2. same question as above for the MQ enabling SPAN db. There is another issue as following: As in the latest WSAD 4(Websphere Application Developer) IDE tool, we can set the transaction context for EJB (whichever entity bean or session bean) and the J2EE container can create transaction-aware pooled DataSource objects and takes care of the transactions being carried out within the same transaction context, can we simply use the transaction-context-awared Session bean to replace the BMP Entity Bean? (as we could use UserTransaction.begin() or .commit() wrapping around the transaction method in the Session Bean) Please note that the BMP Entity Bean would consume more resources than the Session Bean, since the WAS4 provides the transaction monitoring context and auto-roll back features for us, why do we still stick onto the entity bean for communicating with the database? Your help would be highly appreciated! Cheers Victor
You had your fun. Now it's time to go to jail. Thanks for your help tiny ad.
Free, earth friendly heat - from the CodeRanch trailboss