Transaction Management in JMS

If more than one client is trying receive messages from a queue how does JMS manage to send message only to one client.
Lets take a case where there are two clients(Client1 and Client2 having queueReceivers R1 and R2 of sessions session1 and session2 respectively). These clients try to access a single queue and receive messages from it in Client-acknowledge-mode and their sessions being transacted. If Client1 receives message - M1 then what would happen to the message in the queue(will it be deleted/locked/??) in the following senarios:
1) Client1 does not acknowledge the message and does not commit the session. (client1 process dies)
2) Client1 acknowledges the message and does not commit the session.
3) Client1 does not acknowledge the message and commits the session.
During the above cases if Client2 tries to receive a message does it get the same message-M1?

First of all the JMS specification does not define the behavior for multiple clients accessing a queue. Having said that, most vendors do offer this. Since it is not defined in the specification mileage can vary from provider to provider. However, most vendors do the obvious/intuitive thing.
When a client receives a message from a queue it is not available to anyone else until the final disposition of that message can be determined. Acknowledge and commit permanently remove the message from the queue. Recover and rollback put the message back in the queue. The death of the client results in a recover or rollback. When a message goes back to the queue, it is made available to all clients who are waiting (possibly even the same client (except in the case of the dead client)).
With respect to your questions, the intuitive behaviors are:
1) message goes back and someone else has a chance to get it
2) If you have a transacted session then the acknowledge is simply ignored, and since you didn't call commit, the message is still considered outstanding (and no one else can get it). If the session is not transacted then the acknowledge causes the message to be permanently removed from the destination (and no one else can get it).
3) if the session is transacted then the commit permanently removes the message from the destination (and no one else can get it). if the session is not transacted then the commit must throw an exception and since you didn't call acknowledge, the message is still considered outstanding (and no one else can get it).
Client2 could only receive the same message if client1 rolledback or recovered the message (which should occur if client1 dies).
_sjz.

Similar Messages

Transaction Management in JMS adapter

Hi,
I am creating a BPEL process for inserting data in a JMS queue (for producing message on queue) with transaction management, and came across the property "isTransacted", can anyone please help me with the functionality of this property, and how to handle transactions with JMS Queue.
Thanks.

First of all the JMS specification does not define the behavior for multiple clients accessing a queue. Having said that, most vendors do offer this. Since it is not defined in the specification mileage can vary from provider to provider. However, most vendors do the obvious/intuitive thing.
When a client receives a message from a queue it is not available to anyone else until the final disposition of that message can be determined. Acknowledge and commit permanently remove the message from the queue. Recover and rollback put the message back in the queue. The death of the client results in a recover or rollback. When a message goes back to the queue, it is made available to all clients who are waiting (possibly even the same client (except in the case of the dead client)).
With respect to your questions, the intuitive behaviors are:
1) message goes back and someone else has a chance to get it
2) If you have a transacted session then the acknowledge is simply ignored, and since you didn't call commit, the message is still considered outstanding (and no one else can get it). If the session is not transacted then the acknowledge causes the message to be permanently removed from the destination (and no one else can get it).
3) if the session is transacted then the commit permanently removes the message from the destination (and no one else can get it). if the session is not transacted then the commit must throw an exception and since you didn't call acknowledge, the message is still considered outstanding (and no one else can get it).
Client2 could only receive the same message if client1 rolledback or recovered the message (which should occur if client1 dies).
_sjz.

How to define transaction semantics for JMS Queues

Hi,
My scenario in Oracle Fusion Middleware 11gR3, SOA Suite, IDE: JDeveloper 11g is as follows:
First). receive a message from QueueA, Second). Using the message, call a serviceABC and send the same message into QueueB.
I created a syn-BPEL, configured two JMS Adapters(for accessing Queue A & B) and one webservice binding for calling serviceABC(Proxy service). Note: I created the two queues and a connection factory under JMS System Module. As two different external systems have to access QueueA and QueueB.
Now, when I execute the BPEL and ServiceABC gets faulted, the message is gettings consumed from QueueA and the same message is getting produced in QueueB.
My goal is to define a transaction semantics for my composite(syn-BPEL), such that, when ServiceABC or producing the message in QueueB fails. I retain the message in QueueA(basically, rolling back the message).
Options tried so far: 1). Created a scope for the three operations and added a compensationhandler to it and .2). XA Connection Factory is Enabled. Result: no luck:( still message from QueueA is getting consumed where as per my goal it should get rolled-back.
Please suggest your approach, I'll try out and post the outcome back.

Whats your architecture? Are you running your app on an application server? If so, are you in a servlet or EJB? You should be able to get the application server to manage your transactions for you in that case e.g. wrap all the JMS calls in an stateless session bean and give it Required in its transaction attribute of deployment descriptor.
If you're not on an application server, you need to get a transaction manager, either by putting your code in an app server ( with JBoss you can use its transaction manager without necessarily having to use EJBs or Servlets, but thats not tested as thoroughly as the container managed transactions, and you will have to write some of the transaction code yourself ) or using a stand alone one.

Distributed transaction just involving JMS

Hi,
          I have a MDB using a REMOTE DESTINATION to get the messages. The remote
          destination is a Topic using a Connection factory set up as following:
          User Transactions Enabled = true
          XAConnection Factory Enabled = true
          The MDB is set to type-transaction=Container and has a durable
          suscription for the Topic.
          Although, I know I´m using distributed transaction (XAConnection Factory
          Enabled = true) I am not sure if it is correct or not.
          I read that a distributed transaction is when you have 2 resources
          participating in the transaction, but, as you can see I have just JMS
          involved.
          Should I use distributed transaction or not ?
          Any comments will be appreciated!
          Thanks,
          Edith Rivera


ok Thanks for your help !
          Edith
          Peter Holditch wrote:
          > Edith,
          >
          > You should use JTA in the normal way, as you describe.
          >
          > If at commit time there is only 1 participant in the transaction (as
          > seems to ber the case in your instance) then the transaction manager
          > will optimise out the prepare phase of the processing, and you end up
          > with a single phase commit automatically.
          >
          > Regards,
          > Peter.
          >
          > Edith Rivera wrote:
          >
          >> Hi,
          >>
          >> I have a MDB using a REMOTE DESTINATION to get the messages. The
          >> remote destination is a Topic using a Connection factory set up as
          >> following:
          >> User Transactions Enabled = true
          >> XAConnection Factory Enabled = true
          >>
          >> The MDB is set to type-transaction=Container and has a durable
          >> suscription for the Topic.
          >>
          >> Although, I know I´m using distributed transaction (XAConnection
          >> Factory Enabled = true) I am not sure if it is correct or not.
          >> I read that a distributed transaction is when you have 2 resources
          >> participating in the transaction, but, as you can see I have just JMS
          >> involved.
          >>
          >> Should I use distributed transaction or not ?
          >>
          >> Any comments will be appreciated!
          >> Thanks,
          >> Edith Rivera
          >>
          >>
          >

Shared Disk solution for Transaction Logs and JMS?

          In a machine failure, two key resources for a clean recovery are the Transaction Logs
          and the JMS Store.
          The WebLogic Server Administration Guide discusses moving the Transaction Logs to
          a new machine before starting a failed WLS server on that machine in order to achieve
          a clean recovery.
          It suggests use of "a dual-ported disk available to both machines."
          I'm looking for such a solution.
          We currently use Veritas Cluster Server to manage our Database environment, but I
          am concerned it is too expensive or too comprehensive a solution for the size of
          the Transaction Logs and the complexity of the problem.
          Has anyone implemented a solution to achieve high availability of the Transaction
          Logs and JMS Store?
          Can you recommend solutions I should be looking into, in addition to Veritas?
          Thanks,
          Steve Tahmosh
          Sovereign Bank
          617 533-1258


Sully,
OK, I am just about as frustrated as I can get. I'm doing everything that you said, at least as far as I can tell, but all of my Windows machines (two XP, one Vista) are asking me for a username and password and then saying they can't connect.
Any help would be appreciated.
Mitch

CEP Transaction Manager

I have a couple of questions about the transaction manager defined in my CEP server config.xml.
1. Can I use this transaction manager outside of JDBC? I would like to read messages from a JMS queue and write them to a database table in a transaction to ensure that they are not lost. Could I use the transaction manager to do this and if so, how do I get a reference to it?
2. Can I use the commit and rollback methods on a pooled connection object I get from the CEP server or should I be relying on the transaction manager to so that? If I should be relying on the transaction manager, when does the commit happen?
Thanks

(1) The specific case you mention of reading a message from JMS and writing it to the DB in a single transaction isn't currently supported in CEP. This scenario would require XA support in the JMS client used to read the message, and the current JMS client implementation in CEP doesn't have the required XA support. You may be able to get something close to the behavior you want by configuring a transacted session on the inbound JMS adapter. When a transacted session is configured and the code downstream from the inbound adapter throws an exception that propagates back to the JMS adapter, the read of the message will be rolled back and the message will be redelivered. This isn't a distributed transaction, but if you combine this with appropriate error handling on your database update it may meet your requirements. This workaround doesn't require the use of the configured transaction manager.
(2) The transaction manager shouldn't be needed for local JDBC transactions. It would only be needed if you had a requirement for distributed transactions. For local transactions you can use the methods on the connection object directly.

Transaction Help ? JMS and db2 database without appserver

We have a Queue and db2 database.
need to read the message from queue and write it to the database in a standalone application without appserver. Now question is how to have a single transaction for both the jobs?
Please advice!!!

If you want to receive a JMS message and write to a database in the same transaction, then it sounds as if you are asking for the ability to enlist both transactional resources within the same XA transaction and then perform a two-phase commit of the two resources. If you use an application server then this is easy to configure.
Even if you don't want to use an application server (or some other container offering similar services), you will still need a transaction manager, but will need to enlist the transactional resources yourself. Possible but not easy. If an application server is too heavyweight, then look for lighter-weight alternatives.
Nigel

Forte Transaction Management & 2PC

Forte Transaction Management & 2PC
The main purpose of 2PC in a distributed transaction manager is
to enable recovery from a failure that occurs during the window
of transaction commit processing. The Forte transaction manager was built
with this in mind but only with respect to the "volatile" (or "in memory")
objects that Forte manages. What this implies is that because Forte stores
objects in memory and not persistently on disk, the requirement of recovery
for these objects is significantly reduced (if not eliminated all together).
Forte follows a distributed 2PC model in that tasks and messages carry
along with them transaction identification and, during commit processing,
every distributed participant is polled for its availability to commit
the transaction. Applications saving persistent data to disk during a
distributed Forte transaction need to concern themselves with the potential
for failure during the commit processing window. Forte's prepare phase polls
each site (confirming a communications link with each distributed participant)
but no prepare request goes to the database primarily because (in release 1 and
2 of forte) no database supported a general distributed two-phase commit
(one could take issue with that in the case of Sybase, but rather than debate
this point, suffice it to say that the general direction in the industry for
support of this functionality was through TP monitors -- more on that later).
Once all sites are ready to commit Forte expects that the commit will
complete successfully. If at this moment, for example, a participating
Sybase server terminates (with data not yet committed) while a participating
Oracle server has already committed its unit of work, then the outcome of
the distributed transaction is inconsistent - if no one has yet committed
Forte will still abort the transaction. This "window of inconsistency"
is documented in the Forte TOOL manual.
Mission critical applications that require distributed transactions can
address this window of inconsistency in a number of ways:
* Utilize a TP monitor such as Encina (see below)
* Log distributed updates in an auxiliary database table (much like a
distributed transaction monitor's transaction-state log). This approach has
been the traditional banking application solution prior to the commercial
availability of products like Encina, Tuxedo, TopEnd, etc.
This solution is somewhat complex and is usually not generic enough
so as not to have to change code every time a new table or database
site is introduced into the application's data model.
* Rearrange the data model in order to eliminate the need for distributed
transactions. This is usually only a temporary solution (with smaller
numbers of active clients) and cannot be applied to complex legacy systems.
With the advent of the X/Open distributed transaction architecture (the
XA Interface) more database vendors have found that by complying with the
XA interface they can plug their database-specific implementation of
transaction into a globally managed transaction, with commit and abort
processing being conducted by a central coordinator. Of course, the
overall transaction manager coordinating the global transaction must
itself, persistently record the state of the different distributed
branches participating in the transaction. A significant portion of
the functionality provided by products such as Encina, Tuxedo, TopEnd and
OpenTP1 is to provide exactly this global transaction management.
Rather than extend the Forte distributed transaction manager with the
functionality necessary to manage and recover distributed transactions
that modify data on disk, Forte has chosen to integrate with the emerging
set of commercial transaction monitors and managers. This decision was
built into the original design of the Forte transaction model (using XA and
early Tuxedo white-papers as guidelines):
* In Forte release 2 an integration with Encina was delivered.
* In January 1997 a press release announced an integration of
OpenTP1 with Forte for release 3.
* The Forte engineering staff is currently investing integration
with other transaction management products as well.
Neil Goodman,
Forte Development.

You don't. ("manage" a transaction)
There is nothing really to "manage".
A transaction is automatically started when you make any changes to data (e.g. fire off a DML statement).
You simply needs to issue a COMMIT or ROLLBACK when needed. A COMMIT at the end of the business transaction and not before (i.e. no committing every n number of rows). A ROLLBACK when hitting an exception or business logic error that requires the uncommitted changes to be undone.
That in a nutshell is it. It is that simple.
Oracle also supports creating savepoints and rolling back only some changes made thus far in the transaction.
The only other thing to keep in mind that a DDL in Oracle issues an implicit commit. Firing off a DDL with cause any exiting uncommitted transaction to be committed.
Transaction "logic/management" should not be made more complex than this.

Error while Running Receiving Transaction Manager

Hi.,
We have 11..5.10.2 on AIX 5.3 intermeditley we are getting the below error for Receiving Transaction Manager. for temporary sloution we will restart the Receiving Transaction Manager is there any permanent solution for this.....?
we have two Receiving Transaction Manager process.
Error
"APP 00204: Concurrent manager encountered an error while running the spawned
concurrent program Receiving Transaction Manager: rcvoltm TM:Timeout"

Hello.
Have a look on MOS Doc ID 1071727.1
Octavio

Transaction management in stateless session beans.

Hi all,
I am using EJB 1.1.
I have a statless session bean that has two methods- A and B.
which does not involve any database interaction
like inserting/updating/deleting the data in the database.
The process flow is such the client always calls A first followed by the call to B.
I have the Transaction attribute set as TX_REQUIRED at the whole bean level.
Now my question is as follows:
Since it is a stateless bean, ejbCreate() is called for every method's invocation.
So does it mean that a new transaction is started for every method invocation?
Also since a transaction ends by commit/rollback.
The transation associated with the method A/B will never get completed as there is no commit/rollback involved in method implementation.
So how is this transaction ended?
Any more details about the transaction management in stateless session beans is highly appreciated.
Any input at the earliest is highly appreciated.
Thanks in advance.

Since it is a stateless bean, ejbCreate() is called for every method's invocation.For stateless session bean , Create() is not delegated to the instance.
So does it mean that a new transaction is started for every method invocation?This depends opon the Tx attribute and sequence of calls. Since you have given Tx_required then if you call any method and there is no Tx context associated with client,then a new TX will be started by container othere wise it will execute in the same TX context as the calling client. Note that client can be jsp or other ejb method.
Also since a transaction ends by commit/rollback.
The transation associated with the method A/B will never get completed >as there is no commit/rollback involved in method implementation.
So how is this transaction ended?If you are using COntainer managed TX then Transaction handling like starting , ending etc is handled by the container. You need not worry about that.
Any more details about the transaction management in stateless session >beans is highly appreciated.
Any input at the earliest is highly appreciated.Some time back I had read the article on how the Transaction management done by container on IBM Site. I dont have URL , but you can search the site.
HTH
-Ashwani

Receiving Transaction Manager Time out in iProcurement Receiving!

Hi All,
Database:10.2.0.4.0
Oracle Aps:12.0.6
O/S:AIX 64 bits 5.3 L
We are unable to create any receipts due to following error.Checked Receiving Transaction Manager and that is running fine.
Error Message
Your receipt could not be created successfully because your receiving transaction manager timed out.
Please contact your System Administrator for further assistance.
Steps To Reproduce
The issue can be reproduced at will with the following steps:
1. In Iprocurement select requisition to receive
2. Enter required data and press submit
3. on screen receive Items: review and submit get above error message
Profile RCV: Processing Mode is currently set to 'online'
Could anyone please share resolution to such an issue faced before.
Thanks for your time!
Regards,

Follow the Metalink ID: 375152.1

Coherence and EclipseLink - JTA Transaction Manager - slow response times

A colleague and I are updating a transactional web service to use Coherence as an underlying L2 cache. The application has the following characteristics:
Java 1.7
Using Spring Framework 4.0.5
EclipseLink 12.1.2
TopLink grid 12.1.2
Coherence 12.1.2
javax.persistence 12.1.2
The application is split, with a GAR in a WebLogic environment and the actual web service application deployed into IBM WebSphere 8.5.
When we execute a GET from the server for a decently sized piece of data, the response time is roughly 20-25 seconds. From looking into DynaTrace, it appears that we're hitting a brick wall at the "calculateChanges" method within EclipseLink. Looking further, we appear to be having issues with the transaction manager but we're not sure what. If we have a local resource transaction manager, the response time is roughly 500 milliseconds for the exact same request. When the JTA transaction manager is involved, it's 20-25 seconds.
Is there a recommendation on how to configure the transaction manager when incorporating Coherence into a web service application of this type?

Hi Volker/Markus,
Thanks a lot for the response.
Yeah Volker, you are absolutely right. the 10-12 seconds happens when we have not used the transaction for several minutes...Looks like the transactions are moved away from the SAP buffer or something, in a very short time.
and yes, the ABAP WP's are running in Pool 2 (*BASE) and the the JAVA server, I have set up in another memory pool of 7 GB's.
I would say the performance of the JAVA part is much better than the ABAP part.
Should I just remove the ABAP part of the SOLMAN from memory pool 2 and assign the JAVA/ABAP a separate huge memory pool of say like 12-13 GB's.
Will that likely to improve my performance??
No, I have not deactivated RSDB_TDB in TCOLL from daily twice to weekly once on all systems on this box. It is running daily twice right now.
Should I change it to weekly once on all the systems on this box? How is that going to help me?? The only thinng I can think of is that it will save me some CPU utilization, as considerable CPU resources are needed for this program to run.
But my CPU utilization is anyway only like 30 % average. Its a i570 hardware and right now running 5 CPU's.
So you still think I should deactivate this job from daily twice to weekly once on all systems on this box??
Markus, Did you open up any messages with SAP on this issue.?
I remember working on the 3.2 version of soultion manager on change management and the response times very much better than this as compared to 4.0.
Let me know guys and once again..thanks a lot for your help and valuable input.
Abhi

Configuration for Transaction Management

          Hi,
          I am working with Weblogic Server SP1. I am facing a problem in configuring for
          Transaction Management.
          I have a session EJB say SEJB and two entity EJB say EEJB1 and EEJB2. EEJB1 is
          for the parent table
          and EEJB2 is for the child table.
          I have two records in the database REC1 and REC2.
          REC2 has dependencies and cannot be deleted, while REC1 can be deleted.
          In weblogic-ejb-jar.xml I have configured as follows:
          <weblogic-enterprise-bean>
          <ejb-name>SEJB</ejb-name>
          <stateless-session-descriptor>
          <pool>
          <max-beans-in-free-pool>300</max-beans-in-free-pool>
          <initial-beans-in-free-pool>150</initial-beans-in-free-pool>
          </pool>
          </stateless-session-descriptor>
          <reference-descriptor>
               <ejb-reference-description>
               <ejb-ref-name>EEJB</ejb-ref-name>
               <jndi-name>EEJBean</jndi-name>
               </ejb-reference-description>
               </reference-descriptor>
          <jndi-name>SEJBn</jndi-name>
          </weblogic-enterprise-bean>
          Further, in ejb-jar.xml I have set up the <trans-attribute> as RequiresNew for
          Session Bean while Supports
          for the EEJB. Something like this:...
          <container-transaction>
          <method>
          <ejb-name>SEJB</ejb-name>
          <method-intf>Remote</method-intf>
          <method-name>*</method-name>
          </method>
          <trans-attribute>RequiresNew</trans-attribute>
          </container-transaction>
          In spite of this setting, when, through the client, I am selecting the two records
          REC1 and REC2 at the same
          time and deleting them, REC1 gets deleted while REC2 does not and gives a TransactionRollbackException.
          Ideally, since both are part of a single transaction, both should have been rolled
          back.
          Please suggest if I am missing on some kind of configuration parameter or setting.
          I'll be more than
          happy to provide some more details to get the problem solved.
          I can also be reached at [email protected]
          Thanks in advance,
          Regards,
          Rishi


TCode: SWF5
Enterprise_Extensions:
-> EA-FS
Enterprise_Business_Functions:
-> FIN_TRM*
Rg
Lorenz

Transaction Management

Hi there,
I have a number of table manager classes, each of which saves data to
their respective table in the database. With these tables it is likely
that they may be locked by other users on occasion so I have put in
exception handlers on the managers to cater for this. The user has the
option to keep trying or give up and try again later.
Now sometimes three or more tables may need to be updated together and if
one fails to commit then no data for the three tables should be saved to
the database. In such a case the 'save' method of the three or more table
managers are called from a single method within one 'dependent' forte
transaction. Before calling the save methods, I call another method which
starts a SQL 'read write wait 10' transaction reserving each table needed
within the transaction.
I have read through the Transactions chapter of the Forte Accessing
Databases manual and see examples where a number of SQL statements are
included within a transaction and each one commits only if all are
successful at the end of the transaction. I assumed my approach would be
similar especially when using the 'begin dependent transaction' statement.
But if the application gets around to saving the second table which is
locked and the user decides not to commit, the first table is still updated
in the database.
Is it because my SQL statements are in seperate methods and are commited
when the method is complete? Or am I missing something somewhere?
Any help greatly appreciated.
Thank you.
Vanessa.
===========================================< @
===========================================Vanessa Rumball
Analyst Programmer Phone: (03) 479 8285
A.T.S. Fax: (03) 479 5080
University of Otago Email: [email protected]
PO Box 56
Dunedin
New Zealand
===========================================< @
===========================================-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Hello Peter,
Well, we are using a slightly different approach. We have a SO
(we call it Persistence Manager)
and DBSession SO (user visible) in one partition. This partition
is load balanced.
All database activity is in the Persistence Manager - in one
partition that uses one DBSession. In this approach we do not
have possibility for deadlocks between different DBSessions
because for example an activity that involves several tables
will be executed within one DBSession. And since this partition
is load balanced, the access to the database will not be
blocked.
Hope this makes sense.
Best regards,
Dimitar mailto:[email protected]
Monday, May 17, 1999, 1:55:35 PM, you wrote:
PSHAMSDI> Hi,
PSHAMSDI> I would like to add to the question on the concern on sharing DBSession.
PSHAMSDI> The fact that a DBSession is shared and is blocked from other threads within
PSHAMSDI> a transaction make it a candidate for "dead-lock". That's why in my
PSHAMSDI> application, up until now, I dare not to load-balance a DBSession or involve
PSHAMSDI> multiple DBSessions in a update transaction. I have experience that when
PSHAMSDI> multiple DBSessions are involved in a update transaction, there is a great
PSHAMSDI> choice that the DBSessions are dead-locked by different threads.
PSHAMSDI> The way that we do it now is very dumb and hard to maintain. We pass the
PSHAMSDI> DBSession along for all the calls involved in a update transaction.
PSHAMSDI> However, if someone forget to follow the convention, the application will
PSHAMSDI> get dead-locked and I have to use dumb status on the partitions to trace
PSHAMSDI> back the invoking method. It is horrible and with no guarentee to find the
PSHAMSDI> source of the problem.
PSHAMSDI> I have figured a more extensive architecture to solve this problem. But
PSHAMSDI> before I fully implement my design, I would like to know if there is already
PSHAMSDI> a elegant solution out there.
PSHAMSDI> Thanks for any help in advance.
PSHAMSDI> Best regards,
PSHAMSDI> Peter Sham.
PSHAMSDI> -----Original Message-----
PSHAMSDI> From: Dimitar Gospodinov [SMTP:[email protected]]
PSHAMSDI> Sent: Monday, May 17, 1999 2:47 PM
PSHAMSDI> To: Vanessa Rumball
PSHAMSDI> Cc: [email protected]
PSHAMSDI> Subject: Re: Transaction Management
PSHAMSDI> Hello Vanessa,
PSHAMSDI> You should use dependent transactions - the "begin
PSHAMSDI> transaction"
PSHAMSDI> statement is equal to "begin dependent transaction" statement.
PSHAMSDI> So you can have several methods for saving the data in
PSHAMSDI> different
PSHAMSDI> tables - all these method contain "begin transaction .. end
PSHAMSDI> transaction" construction.
PSHAMSDI> Then you can have one "wrapper" method that calls the above
PSHAMSDI> methods. This method also contains "begin transaction .. end
PSHAMSDI> transaction" construction.
PSHAMSDI> Now you have dependent transactions - if some of the
PSHAMSDI> transaction
PSHAMSDI> fails , the whole bunch of transaction will fail.
PSHAMSDI> If you want to catch the Deadlocks you may register for the
PSHAMSDI> AbortException exception and re-try your outermost
PSHAMSDI> transaction.
PSHAMSDI> Hope this helps.
PSHAMSDI> Best regards,
PSHAMSDI> Dimitar mailto:[email protected]
PSHAMSDI> Monday, May 17, 1999, 6:08:17 AM, you wrote:
PSHAMSDI> VR> Hi there,
PSHAMSDI> VR> I have a number of table manager classes, each of which saves
PSHAMSDI> data to
PSHAMSDI> VR> their respective table in the database. With these tables it is
PSHAMSDI> likely
PSHAMSDI> VR> that they may be locked by other users on occasion so I have put
PSHAMSDI> in
PSHAMSDI> VR> exception handlers on the managers to cater for this. The user
PSHAMSDI> has the
PSHAMSDI> VR> option to keep trying or give up and try again later.
PSHAMSDI> VR> Now sometimes three or more tables may need to be updated
PSHAMSDI> together and if
PSHAMSDI> VR> one fails to commit then no data for the three tables should be
PSHAMSDI> saved to
PSHAMSDI> VR> the database. In such a case the 'save' method of the three or
PSHAMSDI> more table
PSHAMSDI> VR> managers are called from a single method within one 'dependent'
PSHAMSDI> forte
PSHAMSDI> VR> transaction. Before calling the save methods, I call another
PSHAMSDI> method which
PSHAMSDI> VR> starts a SQL 'read write wait 10' transaction reserving each
PSHAMSDI> table needed
PSHAMSDI> VR> within the transaction.
PSHAMSDI> VR> I have read through the Transactions chapter of the Forte
PSHAMSDI> Accessing
PSHAMSDI> VR> Databases manual and see examples where a number of SQL
PSHAMSDI> statements are
PSHAMSDI> VR> included within a transaction and each one commits only if all
PSHAMSDI> are
PSHAMSDI> VR> successful at the end of the transaction. I assumed my approach
PSHAMSDI> would be
PSHAMSDI> VR> similar especially when using the 'begin dependent transaction'
PSHAMSDI> statement.
PSHAMSDI> VR> But if the application gets around to saving the second table
PSHAMSDI> which is
PSHAMSDI> VR> locked and the user decides not to commit, the first table is
PSHAMSDI> still updated
PSHAMSDI> VR> in the database.
PSHAMSDI> VR> Is it because my SQL statements are in seperate methods and
PSHAMSDI> are commited
PSHAMSDI> VR> when the method is complete? Or am I missing something
PSHAMSDI> somewhere?
PSHAMSDI> VR> Any help greatly appreciated.
PSHAMSDI> VR> Thank you.
PSHAMSDI> VR> Vanessa.
PSHAMSDI> VR> ===========================================< @
PSHAMSDI> >>===========================================
PSHAMSDI> VR> Vanessa Rumball
PSHAMSDI> VR> Analyst Programmer Phone: (03) 479 8285
PSHAMSDI> VR> A.T.S. Fax: (03) 479 5080
PSHAMSDI> VR> University of Otago Email:
PSHAMSDI> [email protected]
PSHAMSDI> VR> PO Box 56
PSHAMSDI> VR> Dunedin
PSHAMSDI> VR> New Zealand
PSHAMSDI> VR> ===========================================< @
PSHAMSDI> >>===========================================
PSHAMSDI> VR> -
PSHAMSDI> VR> To unsubscribe, email '[email protected]' with
PSHAMSDI> VR> 'unsubscribe forte-users' as the body of the message.
PSHAMSDI> VR> Searchable thread archive
PSHAMSDI> <URL:http://pinehurst.sageit.com/listarchive/>
PSHAMSDI> -
PSHAMSDI> To unsubscribe, email '[email protected]' with
PSHAMSDI> 'unsubscribe forte-users' as the body of the message.
PSHAMSDI> Searchable thread archive
PSHAMSDI> <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Cannot connect to transaction manager

Hi,
i keep on getting this error "cannot connect to the transaction manager or the transaction manager is not available"
my setup is windows 2000, oracle 8i and odbc oracle driver version is 8.1.7.
help please...
regards,
Russell Limcangco

This is very critical for MTS-Oracle to work. Make sure, it points to the right dlls. It varies with the Oracle client version. For 8.1.7 the above registry entry should read like this..
oraclexalib = oraclient8.dll
oraclesqllib = orasql8.dll
oacleocilib = oci.dll

Transaction Management in JMS

Similar Messages

Maybe you are looking for