RE: Re[2]: Transaction Management

Hi,
Thanks for the reply. But my situation may require more than 1 DBSession
per Persistence Manager, as under the same Domain problem, my persistent
objects spread across multiple databases ( due to some legacy and package
systems ).
On the other hand, I think your model would be helpful in some cases.
Following is what I think you are doing in your model in order to make use
of this Persistence Manager.
1. Client program would retrieve business object from this persistence
manager;
2. When persistence manager return the requested object, it would save
its pointer to the business object.
3. When client call save()/delete() on the business object, it would
then route the request to the persistence manager by its pointer.
Please correct me if I'm wrong.
As mentioned, I have another design on this issue. When my document is
ready, would you like to take a look. I just want to invite more opinion on
this "Framework" with which I've spent at least half a year to work on.
Best regards,
Peter Sham.
-----Original Message-----
From: Dimitar Gospodinov [SMTP:[email protected]]
Sent: Monday, May 17, 1999 5:41 PM
To: Peter Sham (HTHK - Assistant Manager - Software Development,
IITB)
Cc: Vanessa Rumball; [email protected]
Subject: Re[2]: Transaction Management
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/>

Hi Bolun,
If you have 2 different UOM(KG and PC) you can see 2 sub-totals only. If you have more, you will see more...
You can try this: Some work around's ........
Option1: Convert other Units of measures into KG's or PC's or
Option2: Add one more Indicator at infoprovider level and populate indicator accordingly., based on UOM and use in report. or
Option3: Make UOM as User Input and restrict report based on that...
Hope it Helps
Srini

Similar Messages

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

@TransactionAttribute annotation being ignored by Transaction Manager

I am currently running jboss-4.0.4GA. I believe I must have something configured incorrectly, or I misunderstand transaction management performed by the container. Though I have my datasource declared as local-tx, which I believe allows transactions, it appears that my a call to a remote function in a stateless session bean is completely executed in one single transaction, regardless of the @TransactionAttribute tags.
In my example, I call a function with @TransactionAttribute = REQUIRED. This is the OUTER FUNCTION. This function inserts a record into the cust table of our database. Then this function calls a second function with @TransactionAttribute = REQUIRES_NEW. This is the INNER FUNCTION.
This function should, according to spec, start up a new transaction independant of the first function. However, the INNER function can select the (un-committed) cust record from the OUTER function. The INNER function then proceeds to add a cust record of its own to the database.
Control then returns to the OUTER function, which can succesfully read the cust record inserted by the INNER function, which is to be expected because the INNER function should have had its transaction committed. However, my program then throws a RuntimeException in order to force a rollback, and this rollback removes both the cust record inserted by the OUTER function and the cust record inserted by the INNER function.
To further my belief that the transaction manager is ignoring my @TransactionAttribute annotations, I change the TransactionAttributeType of the INNER function to "NEVER". According to spec, the code should throw an exception when this function is called within a managed transaction. However, when I run the code I get the exact same behavior as when the INNER function is "REQUIRES_NEW".
I would greatly appreciate if anyone has any insight into what I am doing wrong. Thanks!
Client Program that Invokes TestTransImpl Stateless Session Bean
public class Client{
     public static void main(String[] args) throws Exception {
          try{
               Properties env = new Properties();
                           env.setProperty(Context.SECURITY_PRINCIPAL, "guest");
                           env.setProperty(Context.SECURITY_CREDENTIALS, "guest123");
                           env.setProperty(Context.PROVIDER_URL, "jnp://localhost:1099");
                           env.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
                           env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.JndiLoginInitialContextFactory");
               InitialContext ctx = new InitialContext(env);
               TestTransRemote ttr = (TestTransRemote)ctx.lookup("TestTransImpl/remote");
               ttr.testTransactions();
          }catch(Exception e){
               e.printStackTrace();
               throw e;
}Remote Interface for TestTransImpl Stateless Session Bean
public interface TestTransRemote extends Serializable {
     public void testTransactions() throws Exception;
}TestTransImpl Stateless Session Bean
@Stateless
@Remote(TestTransRemote.class)
public class TestTransImpl implements TestTransRemote {
     private static final long serialVersionUID = 1L;
     @TransactionAttribute(TransactionAttributeType.REQUIRED)
     public void testTransactions() throws Exception{
          java.sql.Connection conn = getConnection();
          java.sql.PreparedStatement ps;
          ps = conn.prepareCall("insert into cust(loc,cust_no) values ('001',20)");
          ps.execute();
          System.out.println("OUTSIDE FUNCTION - Customer 20 created");
          requiredNewFunction();
          ps = conn.prepareCall("Select cust_no from cust where loc = '001' and cust_no = 24");
          java.sql.ResultSet results = ps.executeQuery();
          results.next();
          System.out.println("OUTSIDE FUNCTION - Customer Read - Cust No = " + results.getLong("cust_no"));
          throw new RuntimeException();
     @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
     private void requiredNewFunction() throws Exception{
          java.sql.Connection conn = getConnection();
          java.sql.PreparedStatement ps;
          ps = conn.prepareCall("Select cust_no from cust where loc = '001' and cust_no = 20");
          java.sql.ResultSet results = ps.executeQuery();
          results.next();
          System.out.println("INSIDE FUNCTION - Customer Read - Cust No = " + results.getLong("cust_no"));
          ps = conn.prepareCall("insert into cust(loc,cust_no) values ('001',24)");
          ps.execute();
          System.out.println("INSIDE FUNCTION - Customer 24 created");
     private java.sql.Connection getConnection() throws Exception{
          javax.sql.DataSource ds;
          javax.naming.InitialContext ic = new javax.naming.InitialContext();
          ds = (javax.sql.DataSource)ic.lookup("java:MyOracleDS");
          java.sql.Connection conn = ds.getConnection();
          return conn;
}Datasource XML File
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
    <local-tx-datasource>
        <jndi-name>MyOracleDS</jndi-name>
        <connection-url>jdbc:oracle:thin:XXXXX(DB Host):1521:XXXXX(DB Sid)</connection-url>
        <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
        <user-name>XXXXX(username)</user-name>
        <password>XXXXX(password)</password>
        <min-pool-size>5</min-pool-size>
        <max-pool-size>100</max-pool-size>
        <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
        
        <metadata>
            <type-mapping>Oracle10g</type-mapping>
        </metadata>
    </local-tx-datasource>
</datasources>Program Output
08:43:41,093 INFO [STDOUT] OUTSIDE FUNCTION - Customer 20 created
08:43:41,125 INFO [STDOUT] INSIDE FUNCTION - Customer Read - Cust No = 20
08:43:41,140 INFO [STDOUT] INSIDE FUNCTION - Customer 24 created
08:43:41,140 INFO [STDOUT] OUTSIDE FUNCTION - Customer Read - Cust No = 24

All ejb invocation behavior, including authorization, container-managed transactions, etc. only applies when the call is made through one of the appropriate ejb client objects. If
TestTransImpl.testTransactions() directly invokes requiredNewFunction() it's just a normal java
method call -- the ejb container has no idea it's happening and is not interposing. If you want
the full ejb invocation behavior when you invoke requiredNewFunction() you'll need to
make sure requiredNewFunction is part of a business interface, is public, and is invoked through
the corresponding ejb reference :
@Resource private SessionContext ctx;
public void testTransactions() throws Exception {
TestTransRemote testTrans = ctx.getBusinessObject(TestTransRemote.class);
testTrans.requiredNewFunction();
}

11g TP2 ADF Task Flows and Transaction Management

I'm wondering how ADF Task Flow Transaction Management works vis-a-vis database sessions and using stored procedure calls in an environment with connection pooling. I haven't written the code yet but am looking for a better understanding of how it works before I try.
Example:
I create a bounded adf task flow. I set the "transaction" property to "new-transaction" and the "data control scope" to "isolated".
As the task flow is running, the user clicks buttons that navigate from page to page in the flow. Each button click posts the page back to the app server. On the app server a backing bean method in each page calls a stored procedure in a database package to modify some values in one or more tables in the database. The procedure does not commit these changes.
Each time a backing bean makes a stored procedure call will it be in the same database session? Or will connection pooling possibly return a different database connection and therefore a different database session?
If the transaction management feature of the adf task flows guarantees me that I will always be in the same database session then I don't have to write any extra code to make this work. Will it do that or not?

I don't know if it is documented in the adf documentation currently available for 11g TP2 but what you ask for is a normal transaction management with connection pooling and i can't imagine it is not implemented in ADF BC layer like it is in JPA or other persistence layer.
A transaction will always be executed in the same session. Normally your web session will stay in the same session even you start more than one transaction. You don't have to write any code to manage the session pooling. It is a good practices to customize it at the persistence layer during installation depending on your infrastructure.
Take a look into Fusion Developer Guide ... i'm sure you will find some better explanations about this.

Database transaction management in Web services

Hi,
I am using Oracle8i and firing some database queries from my web services. I want to do the transaction management for the same i.e. When one of the queries fail, i want to rollback. But when i write my own transaction management, it gives me an error :
java.sql.SQLException: Cannot call Connection.commit in distributed transaction.Transaction Manager will commit the resource manager when the distributed transaction is committed.
Can anyone please help me out as to how to perform the database transaction management in web services.
Thanking in advance.
Prashant

Unfortunately to manage transactions over web services there is no viable solution available in market. All implementations come with restrictions e.g. Metro works with only EJBs on Glassfish, JBossTS works on JBoss but not with JAX-WS, Atomikos supports only Axis as of now.
1. See explanation above.
2. Yes, it can be but conditions mentioned above are applied :-)
3. [www.oasis-open.org/committees/ws-tx/|www.oasis-open.org/committees/ws-tx/]
4. Unfortunately as of now I do not see an easy way to this problem.

User submitted Credit Card Historical Transactions Management Report by mis

A user has submitted the 'Credit Card Historical Transactions Management Report' by mistake. They have noticed that as a result of this, the concurrent request appears to have deactivated all iExpense unused transactions up to and including the date that they ran the program which results in a number of cardholders affected are unable to see or acquit their Visa transactions.
We believe this process can be reversed using the same report and choosing "activate transactions" however we just need confirmation that our
assumption is correct and that the request can be reversed. Can anyone please confirm if this can be reversed.
Thanks
Lee

I created a SR with Oracle to confirm this and they said you can run this program. I just wanted to make sure program is safe to run for clearing out outstanding charges for termed employee.If Oracle support confirmed that you can run the program, then I would say go with what they said :)
Thanks,
Hussein

BAPI's for Transaction Manager: Is there any BAPI for Stock Options

Hi gurus,
We are using almost every BAPI for Transaction Manager module at FSCM-Treasury & Risk Management (ECC 6.0).
We have forex swaps, forex forwards, forex spot deals, interest rate swaps, cross currency swaps, equity swaps, and we also have a stock options plan.
We need to use a BAPI to automatically create stock options, importing data from other stock options alreaedy created (manually, by the user) in the system.
Do you know if there is any specific functionality for this?
Thanks in advance and kind regards.
Borja

Hi Borja,
if I understand you correct then you want to create a stock option like you can do it manually with the transaction FWZZ. Try the BAPI BAPI_FP_CREATEFROMDATA. With this function module it is possible to create different types of securities like listed options or futures too.
Regards
Robert

Java user-defined transaction management not working correctly???

Hi everyone,
I have encountered a problem when using Java user-defined transaction management in my session bean. It threw an exception but I could not work out what that means. Could anyone comment on this? Thanks.
This BrokerBean is a stateless session calling other entities bean to perform some simple operations. There are 2 Cloudscape databases in use. Invoices (EB) use InvoiceDB and all the other EBs use StockDB.
If I comment out the user-defined transaction management code, then everything works fine. Or if I comment out the Invoices EB code, it is fine as well. It seemed to me that there is something wrong in transaction management when dealing with distributed databases.
--------------- source code ----------------------
public void CreateInvoices(int sub_accno) {
try {
utx = context.getUserTransaction();
utx.begin();
SubAcc subAcc = subAccHome.findByPrimaryKey(new SubAccPK(sub_accno));
String sub_name = subAcc.getSubName();
String sub_address = subAcc.getSubAddress();
Collection c = stockTransHome.findBySubAccno(sub_accno);
Iterator i = c.iterator();
ArrayList a = new ArrayList();
while (i.hasNext()) {
StockTrans stockTrans = (StockTrans)i.next();
int trans_id = stockTrans.getTransID();
String tran_type = stockTrans.getTranType();
int stock_id = stockTrans.getStockID();
float price = stockTrans.getPrice();
Invoices invoices = invoicesHome.create(sub_accno, sub_name, sub_address, trans_id, stock_id, tran_type, price);
stockTrans = stockTransHome.findByPrimaryKey(new StockTransPK(trans_id));
stockTrans.remove();
utx.commit();
utx = null;
} catch (Exception e) {
if (utx != null) {
try {
utx.rollback();
utx = null;
catch (Exception ex) {}
// e.printStackTrace();
throw new EJBException("BrokerBean.CreateInvoices(): " + e.getMessage());
--------------- exception ----------------------
Initiating login ...
Enter Username:
Enter Password:
Binding name:`java:comp/env/ejb/BrokerSB`
EJB test succeed
Test BuyStock!
Test BuyStock!
Test BuyStock!
Test BuyStock!
Test SellStock!
Test SellStock!
Caught an exception.
java.rmi.ServerException: RemoteException occurred in server thread; nested exce
ption is:
java.rmi.RemoteException: BrokerBean.CreateInvoices(): CORBA TRANSACTION
_ROLLEDBACK 9998 Maybe; nested exception is:
org.omg.CORBA.TRANSACTION_ROLLEDBACK: vmcid: 0x2000 minor code: 1806
completed: Maybe
at com.sun.corba.ee.internal.iiop.ShutdownUtilDelegate.mapSystemExceptio
n(ShutdownUtilDelegate.java:64)
at javax.rmi.CORBA.Util.mapSystemException(Util.java:65)
at BrokerStub.CreateInvoices(Unknown Source)
at Client.main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.sun.enterprise.util.Utility.invokeApplicationMain(Utility.java:22
9)
at com.sun.enterprise.appclient.Main.main(Main.java:155)
Caused by: java.rmi.RemoteException: BrokerBean.CreateInvoices(): CORBA TRANSACT
ION_ROLLEDBACK 9998 Maybe; nested exception is:
org.omg.CORBA.TRANSACTION_ROLLEDBACK: vmcid: 0x2000 minor code: 1806
completed: Maybe
at com.sun.enterprise.iiop.POAProtocolMgr.mapException(POAProtocolMgr.ja
va:389)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:43
1)
at BrokerBean_EJBObjectImpl.CreateInvoices(BrokerBean_EJBObjectImpl.java
:265)
at BrokerBeanEJBObjectImpl_Tie._invoke(Unknown Source)
at com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatchToServant(Ge
nericPOAServerSC.java:520)
at com.sun.corba.ee.internal.POA.GenericPOAServerSC.internalDispatch(Gen
ericPOAServerSC.java:210)
at com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispatch(GenericPOAS
erverSC.java:112)
at com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:255)
at com.sun.corba.ee.internal.iiop.RequestProcessor.process(RequestProces
sor.java:84)
at com.sun.corba.ee.internal.orbutil.ThreadPool$PooledThread.run(ThreadP
ool.java:99)

Three things:
first, maybe you should think of putting ut.begin() just before the invoicesHome.create() method and ut.commit() just after the stockTrans.remove() method.It wont solve the current problem but will help in performance once the problem is solved.
second, your utx.commit() is outside the try block. how come the code is compiling then??
third, try doing a SOP call before and after invoicesHome.create() method and see where the problem actually lies.
let us know...
Hi SteveW2,
Thanks for being so helpful. Here are my replies:
Can I just ask why you're not using containermanaged
transactions?The reason why I didn't use container managed
transactions is because I don't really know how to do
that. I am more familiar with this user-defined
transaction handling.
I have attempted to implement the same method in an
entity bean and just let the container manage the
rollback itself. The same exception was thrown when
running the client.
Also, the transaction behaviour is likely to relateto
the app server youre using - which is it?What do you mean by the app server? I am using J2EE
1.3.1 if that is what you meant.
Finally, if your code has a problem rolling back,and
throws an exception, you discard your exception
thereby losing useful information.I have tried to print the exception stack as well, but
it is the same as just printing the general
exception.
This problem is very strange cause if I comment out
the transaction management thing, then everything
works fine. Or if I am only working with 1 single
database, with this user-defined transaction handling,
everything works fine as well.
Here is the error log from J2EE server if you are
interested.
------------ error log ---------------
javax.ejb.TransactionRolledbackLocalException:
Exception thrown from bean; nested exception is:
javax.ejb.EJBException: ejbCreate: Connection
previously closed, open another Connection
javax.ejb.EJBException: ejbCreate: Connection
previously closed, open another Connection
     at InvoicesBean.ejbCreate(Unknown Source)
at
InvoicesBean_RemoteHomeImpl.create(InvoicesBean_Remote
omeImpl.java:31)
     at InvoicesHomeStub.create(Unknown Source)
     at BrokerBean.CreateInvoices(Unknown Source)
at
BrokerBean_EJBObjectImpl.CreateInvoices(BrokerBean_EJB
bjectImpl.java:261)
at BrokerBeanEJBObjectImpl_Tie._invoke(Unknown
Source)
at
com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispa
chToServant(GenericPOAServerSC.java:520)
at
com.sun.corba.ee.internal.POA.GenericPOAServerSC.inter
alDispatch(GenericPOAServerSC.java:210)
at
com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispa
ch(GenericPOAServerSC.java:112)
at
com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:25
at
com.sun.corba.ee.internal.iiop.RequestProcessor.proces
(RequestProcessor.java:84)
at
com.sun.corba.ee.internal.orbutil.ThreadPool$PooledThr
ad.run(ThreadPool.java:99)
javax.ejb.TransactionRolledbackLocalException:
Exception thrown from bean; nested exception is:
javax.ejb.EJBException: ejbCreate: Connection
previously closed, open another Connection
at
com.sun.ejb.containers.BaseContainer.checkExceptionCli
ntTx(BaseContainer.java:1434)
at
com.sun.ejb.containers.BaseContainer.postInvokeTx(Base
ontainer.java:1294)
at
com.sun.ejb.containers.BaseContainer.postInvoke(BaseCo
tainer.java:403)
at
InvoicesBean_RemoteHomeImpl.create(InvoicesBean_Remote
omeImpl.java:37)
     at InvoicesHomeStub.create(Unknown Source)
     at BrokerBean.CreateInvoices(Unknown Source)
at
BrokerBean_EJBObjectImpl.CreateInvoices(BrokerBean_EJB
bjectImpl.java:261)
at BrokerBeanEJBObjectImpl_Tie._invoke(Unknown
Source)
at
com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispa
chToServant(GenericPOAServerSC.java:520)
at
com.sun.corba.ee.internal.POA.GenericPOAServerSC.inter
alDispatch(GenericPOAServerSC.java:210)
at
com.sun.corba.ee.internal.POA.GenericPOAServerSC.dispa
ch(GenericPOAServerSC.java:112)
at
com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:25
at
com.sun.corba.ee.internal.iiop.RequestProcessor.proces
(RequestProcessor.java:84)
at
com.sun.corba.ee.internal.orbutil.ThreadPool$PooledThr
ad.run(ThreadPool.java:99)
What is "connection previously closed, open another
connection"? This might be the cause of the
exception.
I'll keep trying till I solve the problem.
Thanks,
Sasuke

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.

RE: Re[2]: Transaction Management

Similar Messages

Maybe you are looking for