Forte:Transaction Handling

Hi ,
Iam trying to run an independent transaction using the start task statement
transaction.beginIndependent();
sql insert into ORDER_TBL (orderId) values (:int_var) on session DBSessionSO;
if (int_var % 5 = 0) then
event case
postregister
start task m3(int_var) where completion = event,transaction = independent;
when m3_returnValue do
task.part.logmgr.putline('returning m2_exceptionValue');
when m3_exceptionValue do                    task.part.logmgr.putline('returning m2_exceptionValue');
     end event;
end if;
if (int_var % 10 = 0) then
transaction.Abort();
else
transaction.commit();
end if;
In my start task statement if I specify that the transaction is 'independent'
then the prog hangs
but if I specify that the transaction is 'dependent'
it works fine with the expected output.
Please let me know as to where Iam going wrong.
Thanks in advance

You'll need 2 dbsessions if you want to execute two transactions in the same server on two different tasks.
A dbsession is a transactional object and a shared object so if the parent task accessed the dbsession within a transaction then the new task will wait until the parent task has completed.
this may be the cause of your deadlock.

Similar Messages

Transaction Handling in Forte

I have a serious problem with Forte Transaction handling.
If a transaction gets aborted through the statement Transaction.Abort
(not because of a database exception), looks like some resources/locks
are not released as a result of which if the current screen is closed,
Forte does not allow the screen to be re-opened. It gives some vague
error like 'Incorrect syntax near '.'
Following is the piece of code. I would appreciate it if someone could
give me a solution.
Thanks,
Begin Transaction
commitFlag = true;
Function1(commitFlag);
if commitflag
Function2(commitFlag);
end if;
if NOT commitflag
ex :UserDefinedException = new;
Transaction.Abort(ex,true);
end if;
Exception
When ex : UserDefinedException do
End Transaction;
Function1(commitFlag In/Out)
SQL Select some_flg from some_tab;
If some_flag = 'A'
ex : UserDefinedException = new;
commitFlag = false;
raise ex;
end if;
update some_tab with some_flg;
Exception
when ex:UserDefinedException do
Function2(commitFlag In/Out)
SQL Select some_flg from another_tab;
If some_flag = 'A'
ex : UserDefinedException = new;
commitFlag = false;
raise ex;
end if;
update another_tab with some_flg;
Exception
when ex : UserDefinedException do
}

Transaction processing in FORTE is not straight forward. The wrong order
of statements may break your code. In your example I can suggest to
remove exceptions processing blocks from methods Function1 and
Function2. If transaction aborts in Function1, Function2 won't be
executed, so you don't need to use your commitFlag. You should process
an exception what is generated by transaction.abort in the same method
where transaction started or higher, otherwise it does work properly.
Hope it helps.
Igor Teselko.
RAO Meena wrote:
>
I have a serious problem with Forte Transaction handling.
If a transaction gets aborted through the statement Transaction.Abort
(not because of a database exception), looks like some resources/locks
are not released as a result of which if the current screen is closed,
Forte does not allow the screen to be re-opened. It gives some vague
error like 'Incorrect syntax near '.'
Following is the piece of code. I would appreciate it if someone could
give me a solution.
Thanks,
Begin Transaction
commitFlag = true;
Function1(commitFlag);
if commitflag
Function2(commitFlag);
end if;
if NOT commitflag
ex :UserDefinedException = new;
Transaction.Abort(ex,true);
end if;
Exception
When ex : UserDefinedException do
End Transaction;
Function1(commitFlag In/Out)
SQL Select some_flg from some_tab;
If some_flag = 'A'
ex : UserDefinedException = new;
commitFlag = false;
raise ex;
end if;
update some_tab with some_flg;
Exception
when ex:UserDefinedException do
Function2(commitFlag In/Out)
SQL Select some_flg from another_tab;
If some_flag = 'A'
ex : UserDefinedException = new;
commitFlag = false;
raise ex;
end if;
update another_tab with some_flg;
Exception
when ex : UserDefinedException do

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.

Transaction Handling - JDBC Receiver Adapter - Multiple SP Calls

Hello,
I have the following scenario:
I send an XML-SQL structure with multiple statment elements (each of them calling a different stored procedure). A stored procedure raises an error back to the JDBC Receiver Adapter in case of error.
Is it possible to have transaction handling in the JDBC Receiver to ensure:
- Commit only after ALL stored procedures where succesful (no error risen during calls)
- Rollback of ALL already called stored procedures in case an error has been risen
How can I implement these requirements in the JDBC Receiver Adapter?

One more comment, I have found the following info for JDBC Drivers:
<i> "JDBC driver's default is to autocommit, meaning that the result of every SQL statement is permanent as soon as it is executed. This is why the course hasn't had to be concerned with transactions so far, and is perfectly acceptable in many cases."</i>
So I think that each SP-Call is automatically commited in case autocommit on JDBC Driver Level is set to "true". Does anyone know where I can change these settings? Directly on JDBC Receiver Adapter or do I have to go to Visual Admin for those changes?

Removing the entity object commit from transaction handler

Hi,
The business reuirement of the OAFWK page developed by us is as explained below:
The basic functionality is of updating the attributes of items attached to the change order.
The UI components displayed in the page(Item attribute changes region) are built based on the properties of the item attributes as LOV,poplist,textbox etc..
The dynamic VO mapped to these UI components is based on a standard entity object.
User operation:Select any attribute group and click on Go button.The Item attributes of the attribute group are displayed.Enter values in the Item Attributes and click on Apply button of the region.(changes made in the attributes related to the attribute group are committed to the database using
<Root AM>.getTransaction.commit()).
Now we have two such regions in the same page.
On top of the page the item attributes of _{color:#800000}<Item Type X>{color}_ are displayed.
Down the page, the item attributes of {color:#0000ff}<_Item Type Y_>{color} are displayed.
In few special cases i.e for few item attributes, on click of Apply button for {color:#0000ff}_Item Y_{color} , the attributes of {color:#800000}I_tem X_{color} are to be updated by calling a PLSQL API.When Apply button in the Item attributes of _{color:#0000ff}Item Type Y{color}_ is clicked,the execution of controllers is :
1.Controllers of Item attribute changes region of {color:#800000}<Item Type X> {color}The dynamic VO is built for the item attributes of Item Type X
2.Controllers of the Item attribute changes region of {color:#0000ff}Item Type Y{color} The dynamic VO is built for the item attributes of Item Type Y.In the last controller of the hierarchy, the PLSQL API call is included(by invoking the method in AM) to update few attribute values of {color:#800000}Item Type X and finally <Root AM>.getTransaction().commit().
Problem : The updated values by PLSQL API for {color:#800000}_Item Type X_{color} are not reflected in the database but indeed the values entered by user for {color:#800000}_Item Type X_{color} in the top of the page are committed(The Apply button for {color:#800000}_Item Type X_{color} is not clicked).
_>>Please note that the dynamic VOs of both the Item Types are built on the same standard Entity Object_
I am struggling to know the reason why the values updated by PLSQL API are overwrittem by the values in the entity object even though the PLSQL API is called in the last controller of execution.Please let me know if there is any OAFWK constraint.
I tried the approach of removing the commit of the dynamic VO built in the region of {color:#800000}_Item Type X>_ {color}{color:#000000}I fetched the entity implementation of the dynamic VO row and used removeandRetain(),revert().But this approach failed.I am referring to the jdevdoc for the built-in methods.
{color}
Now the requirement is the latest values updated by API (for {color:#800000}_Item Type X_{color}) should be committed in the database but not the values updated by the entity object for {color:#800000}_Item Type X_ {color}{color:#000000}in the item attributes region{color}.
There should a single commit for the entire transaction of the page.
Is there any chance to remove the commit of item attributes of {color:#800000}_Item X_{color} alone from the transaction handler?There are few methods in oracle.jbo.server.EntityImpl class such as doRemoveFromTransactionManager().But these methods are either protected or private.So classes of other packages cannot access them.
So pelase suggest me if there is a workaround for this scenario.
Thanks and Regards,
Kiran
Edited by: Kiran.A on Sep 20, 2008 3:34 AM

Hi Sumit,
Yes I agree on that front that updating the same record through PLSQL and EO is not the right approach.
But the business requirement is as such and we do not have any workaround for this.
Please let me know if there is any way to avoid the EO commit by removing from transaction listener.
Regards,
Kiran

Is ths Transaction Handling Write or Wrong ?

I little bit hesitate about Transaction handling in my application. I want to add data to database, before do this following steps should happen
# add data to account table
# update account serial which locate another table
# add data to monthtrm table
# update monthtrm serial which locate another table
In order to success this step I used container manager transaction below show that code
@TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void addNewFixDepositAccount(Account account, String cusId, String branchCode, int newSerial, String userCode) {
        try {
          //add data to account table
          this.create(account);
                //update the SystemParameter table with new saving serial
                systemParameterFacade.setFdSerial(newSerial);
          //add data to monthtrn tabel
          monthTrnFacade.create(monthTrn);
                //update the SystemParameter table with new monthtrn serial
                systemParameterFacade.setTrnSerial(nxtTranSerial);
     } catch (CopException e) {
     if (e.getStackTrace().length > 0) {
                System.out.println("Custom Massage :-" + e.getMessage());
                System.out.println("Called Class :-" + e.getCalledClass());
                System.out.println("Exception Handling Class :- " + getClass());
                System.out.println("Calling Method :-" + Thread.currentThread().getStackTrace()[1].getMethodName());
                System.out.println("Called Method :-" + e.getCalledMethod());
                System.out.println("Exception Line Number :-" + e.getStackTrace()[21].getLineNumber());
                System.out.println("Date and Time :- " + e.getDateTime());
                System.out.println("Exception Type :-" + e.getCause().toString());
            } else {
                System.out.println("Custom Massage :-" + e.getMessage());
                System.out.println("Called Class :-" + e.getCalledClass());
                System.out.println("Exception Handling Class :- " + getClass());
                System.out.println("Calling Method :-" + Thread.currentThread().getStackTrace()[1].getMethodName());
                System.out.println("Called Method :-" + e.getCalledMethod());
                System.out.println("Date and Time :- " + e.getDateTime());
                System.out.println("Exception Type :-" + e.getCause().toString());
}   Add data to account
    public void create(Account account) throws CopException {
        try {
            em.persist(account);
            em.flush();
            em.clear();
        } catch (Exception e) {
            context.setRollbackOnly();
            throw new CopException("Can't Add Account", e, getClass().toString(), Thread.currentThread().getStackTrace()[1].getMethodName());
Add data to monthtrn
    public void create(MonthTrn monthTrn) throws CopException {
        try {
            em.persist(monthTrn);
            em.flush();
            em.clear();
        } catch (Exception e) {
            context.setRollbackOnly();
            throw new CopException("Can't Add MonthTrm", e ,getClass().toString(),Thread.currentThread().getStackTrace()[1].getMethodName());
Update Account serial
    public void setFdSerial(int fdSerial) throws CopException {
        try {
            Query query = em.createQuery("UPDATE SystemParameter s SET s.fdSerial = :fdSerial");
            query.setParameter("fdSerial", fdSerial);
            query.executeUpdate();
            em.flush();
        } catch (Exception e) {
            context.setRollbackOnly();
            throw new CopException("Can't Update FD Serial", e, getClass().toString(), Thread.currentThread().getStackTrace()[1].getMethodName());
   Update Trnserial
    public void setTrnSerial(int trnSerial) throws CopException {
        try {
            System.out.println("Trn Serial : " + trnSerial);
            Query query = em.createQuery("UPDATE SystemParameter s SET s.trnSerial = :trnSerial");
            query.setParameter("trnSerial", trnSerial);
            int result = query.executeUpdate();
            System.out.println("Number of updated records in transaction Serial :- " + result);
        } catch (Exception e) {
            context.setRollbackOnly();
            throw new CopException("Can't Update Trn Serial", e, getClass().toString(), Thread.currentThread().getStackTrace()[1].getMethodName());
    }Exception Class
package bank.exception;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import javax.ejb.ApplicationException;
* @author dinesh
@ApplicationException(rollback = true)
public class CopException extends Exception {
    private String calledClass;
    private String calledMethod;
    public String getDateTime() {
        DateFormat dateFormat = new SimpleDateFormat(" yyyy-MM-dd HH:mm:ss");
        java.util.Date date = new java.util.Date();
        return dateFormat.format(date);
    public CopException(String string, Exception ae, String className, String methodName) {
        super(string, ae);
        this.getDateTime();
        this.setCalledClass(className);
        this.setCalledMethod(methodName);
    public String getCalledClass() {
        return calledClass;
    public void setCalledClass(String calledClass) {
        this.calledClass = calledClass;
    public String getCalledMethod() {
        return calledMethod;
    public void setCalledMethod(String calledMethod) {
        this.calledMethod = calledMethod;
Is this way correctly handle Transaction? If I wrong please give me you're precious advice to improve my program efficiency, please give some comments

Sounds fine to me. If you have duplicated yourself too much, you can refactor the model later to remove duplication. If there is no duplication, then separate models was the right choice.

Transaction Handling in webservice based partnerlink

What is the transaction handling mechanism for parnerlink which calls webservice (not native BPEL/ESB)?
REgards
priyadarshi

It is SDO using I think
It should be not SOAP action, because it is not support transactions

Transaction handling in Siebel

Hi
Can I implement transaction handling in Siebel? If yes, how can I implement it?
Thanks
Gana

This pdf give some background on transactions and error handling within esb 10g.
http://www.oracle.com/technology/products/integration/esb/files/esb-transactions-errorhandling.pdf
not very detailed

Transaction Handling across Procedures

In the ODI Best Practice Guide for Data Warehouses I came across the following (page 100):
"ODI procedures include an advanced mechanism for transaction handling across multiple steps or even multiple procedures."
It states that transaction handling can occur across multiple procedures. I could not get this to work.
I created a procedure with just one step that inserts into a table. In the step I have set the Transaction dropdown to Transaction 0 and the Commit dropdown to No Commit. However, when I execute the procedure the insert is committed as we terminate the session.
Any ideas how this commit can be prevented?

ok, I figured out that parameters to the JDBC driver can be specified at the properties tab of the data server.
So I presume this will be autocommit = false or sth. similar
I still have to try this out.

Osb 11g transaction handling

Hi,
I have a problem with transaction handling in OSB 11g. When I add a report action, error messages disappear.
The process is the following:
jms-queue -> proxy-service ->business-service ->EBS webservice.
In the proxy-service I add an error-handler at node-level. In this error-handler I log the error-message in the server log. In the regular process there is a request and response-pipeline.
When I add a message on the queue and when the response from EBS is negative, the message is placed on a errorqueue. That's ok.
When I add a report-action to the error-handler and then I put another message on the queue, the message is disappeared. It is not on the error-queue and not on the normal queue. When I look in the database there is an extra row added.
I use the default datasource(wlsbjmsrpDataSource).
I found for example this blog: http://biemond.blogspot.nl/2010/11/global-transactions-and-quality-of.html ; but I can't find an example with writing to a database and a rollback to an errorqueue. The report-action needs it's own transaction.
In the weblogic console -> datasources -> transaction I unchecked "Keep Connection After Local Transaction" but that didn't work.
What kind of options is possible?
Herman

I cant believe i was answered by the famous Anuj!.
You were correct. The weird thing, is that in publish actions the QoS is not propagated onto the target of that Publish per se.
We say this, becouse the Local PS has the Transaction Required = True, ergo the QoS is Exactly Once all along its message flow. It also propagates in the service callout´s and Route Node´s. Thats why we, trying to avoid redundance, didnt specified it in the publish action.
Thank you very much.
Regards.
Mario.

Transaction handling in EJBs

i dont know ejb�s handle transaction.
any sugesstions??????
sorry my english, ciao

http://www.google.com/search?hl=en&q=EJB+transaction+handling
Especially look at this one:
http://www.kevinboone.com/ejb-transactions.html

Web Service transaction handling

Hello,
Is it possible in SAP NW to execute several calls to Web Services in one LUW (logical unit of work)? And be able to commit or rollback?
Where can i find information about Web Service transaction handling in SAP?
Best regards
Ute

I haven't found any official info on it, but my simple testing (mainly via ST05) indicates that you should be able to call multiple web services within a single LUW - there seems to be no implicit "commit work" issued by the framework (unlike remote RFC calls).
Jonathan

Re: FORTE Libraries handling (between interfaces andimplementations) q

From [email protected] Wed Feb 24 07:24:54 1999
Subject: FORTE Libraries handling (between interfaces and implementations)
question
Hi,
When a plan gets distributed as library, a '.sl' file is generated, as well as a
pex file and some header files.
When we need that library, we 'should' include that generated pex file in the
workspace used for the distribution.
What's the impact of keeping the original ('implementation'?) plan for the
library, and not replacing it with the generated
pex file ?
J-Paul Gabrielli & Charles Abecassis
Sema DTS
The result would be that you're not using the library version of the plan.
Instead, you'll have a separate copy built into your image repository
or executable. In other words, it will be as if you'd never generated
the plan as a library.
Mike Schilling
Forte Software
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

From [email protected] Wed Feb 24 07:24:54 1999
Subject: FORTE Libraries handling (between interfaces and implementations)
question
Hi,
When a plan gets distributed as library, a '.sl' file is generated, as well as a
pex file and some header files.
When we need that library, we 'should' include that generated pex file in the
workspace used for the distribution.
What's the impact of keeping the original ('implementation'?) plan for the
library, and not replacing it with the generated
pex file ?
J-Paul Gabrielli & Charles Abecassis
Sema DTS
The result would be that you're not using the library version of the plan.
Instead, you'll have a separate copy built into your image repository
or executable. In other words, it will be as if you'd never generated
the plan as a library.
Mike Schilling
Forte Software
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

RE: FORTE Libraries handling (between interfaces andimplementati ons)

Charles..
If you are talking about different repositories in a single environment, I
am guessing the uuid of the pex file has to be the same. I am not sure if
the pex file forte creates will have the same uuid as the pex file you
obtain when you export with uuid from fscript. If uuid is important for
installed libraries, which I think is true, then there-in lies the impact!!
Cheers!!
-Ravi Kalidindi
Born Info Svcs Group
-----Original Message-----
From: Charles Abecassis [SMTP:[email protected]]
Sent: Wednesday, February 24, 1999 9:18 AM
Cc: '[email protected]'
Subject: FORTE Libraries handling (between interfaces and
implementations) question
Hi,
When a plan gets distributed as library, a '.sl' file is generated, as
well as a
pex file and some header files.
When we need that library, we 'should' include that generated pex file in
the
workspace used for the distribution.
What's the impact of keeping the original ('implementation'?) plan for the
library, and not replacing it with the generated
pex file ?
J-Paul Gabrielli & Charles Abecassis
Sema DTS
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <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/>

thanks a lot.
But when the plan is distributed, there's no way of revealing the code that made it, isn't it ?
-----Message d'origine-----
De: Wang, Tien [SMTP:[email protected]]
Date: mercredi 24 fevrier 1999 18:26
A: 'Charles Abecassis'; 'Kalidindi, Ravi CWT-MSP'
Cc: '[email protected]'
Objet: RE: FORTE Libraries handling (between interfaces and implementati ons) question
Hi Charles & Ravi,
Another aspect of this subject is:
Many times, libraries are designed to give to someone without revealing
your code. If you decide to have the original project included, this
means your program will use it as a supplier plan. It also implies your
program will have knowledge of the original project and its parent
supplier plans and so on.
If you don't care about revealing your original code and dragging all
the related projects into your program, it's fine. It has advantage:
if you decide to change something in your original project, you can just
run it without re-making distribution as a library.
However, if your original project seems pretty stable and can be shared
by other application, making it as a library is not a bad idea.
Hope this helps.
Regards,
Tien Wang
Indus Consultancy Services
(201) 261-3100 ext 236
[email protected]
www.indcon.com
From: Kalidindi, Ravi CWT-MSP[SMTP:[email protected]]
Reply To: Kalidindi, Ravi CWT-MSP
Sent: Wednesday, February 24, 1999 11:47 AM
To: 'Charles Abecassis'
Cc: '[email protected]'
Subject: RE: FORTE Libraries handling (between interfaces and
implementati ons) question
Charles..
If you are talking about different repositories in a single
environment, I
am guessing the uuid of the pex file has to be the same. I am not sure
if
the pex file forte creates will have the same uuid as the pex file you
obtain when you export with uuid from fscript. If uuid is important
for
installed libraries, which I think is true, then there-in lies the
impact!!
Cheers!!
-Ravi Kalidindi
Born Info Svcs Group
-----Original Message-----
From: Charles Abecassis
[SMTP:[email protected]]
Sent: Wednesday, February 24, 1999 9:18 AM
Cc: '[email protected]'
Subject: FORTE Libraries handling (between interfaces and
implementations) question
Hi,
When a plan gets distributed as library, a '.sl' file is generated,as
well as a
pex file and some header files.
When we need that library, we 'should' include that generated pexfile in
the
workspace used for the distribution.
What's the impact of keeping the original ('implementation'?) planfor the
library, and not replacing it with the generated
pex file ?
J-Paul Gabrielli & Charles Abecassis
Sema DTS
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive<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/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <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/>

Exception generated during defered local transaction handling

Hi All,
We are using data direct connect 3.3 driver with MS SQL Server 7 on WebSphere 4.0. We are getting the exception "Exception generated during defered local transaction handling". Anyone encountered similar problem?> please let me know the solution. I am pasting the stack trace here.
Thanks in advance.
Regards,
Girish
[7/29/05 9:19:31:210 EDT] 37c1f1 SystemOut U 2005-07-29 09:19:31,177 [Servlet.Engine.Transports:10] ERROR com.xyz.nuuw.bus.dao.JDBCWrapper -livdsqa11122643171177
java.sql.SQLException: [IBM][SQLServer JDBC Driver]Exception generated during defered local transaction handling. See next exception via SQLException.getNextException for details.
at com.ibm.websphere.jdbc.base.BaseExceptions.createException(Unknown Source)
at com.ibm.websphere.jdbc.base.BaseExceptions.getException(Unknown Source)
at com.ibm.websphere.jdbc.base.BaseExceptions.getException(Unknown Source)
at com.ibm.websphere.jdbc.base.BaseConnection.transactionableWorkStarting(Unknown Source)
at com.ibm.websphere.jdbc.base.BaseStatement.commonExecute(Unknown Source)
at com.ibm.websphere.jdbc.base.BaseStatement.executeQueryInternal(Unknown Source)
at com.ibm.websphere.jdbc.base.BasePreparedStatement.executeQuery(Unknown Source)
at com.ibm.websphere.jdbcx.base.BasePreparedStatementWrapper.executeQuery(Unknown Source)
at com.ibm.ejs.cm.cache.CachedStatement.executeQuery(CachedStatement.java:312)
at com.ibm.ejs.cm.proxy.StatementProxy.executeQueryCommon(StatementProxy.java:410)
at com.ibm.ejs.cm.proxy.PreparedStatementProxy.executeQuery(PreparedStatementProxy.java:53)
at com.xyz.nuuw.bus.dao.JDBCWrapper.getdata(JDBCWrapper.java:164)
at com.xyz.nuuw.bus.dao.AccountSetupPH.getKeyID(AccountSetupPH.java:445)
at com.xyz.nuuw.bus.bo.AccountSetupBO.getKeyID(AccountSetupBO.java:50)
at com.xyz.nuuw.accountSetup.bus.ejb.AccountSetupSBBean.getKeyID(AccountSetupSBBean.java:85)
at com.xyz.nuuw.accountSetup.bus.ejb.EJSRemoteStatelessAccountSetupSB_14ea1086.getKeyID(EJSRemoteStatelessAccountSetupSB_14ea1086.java:99)
at com.xyz.nuuw.accountSetup.bus.ejb._AccountSetupSB_Stub.getKeyID(_AccountSetupSB_Stub.java:310)
at com.xyz.nuuw.bus.AccountSetupBD.getKeyID(AccountSetupBD.java:73)

I am currently working with IBM on a similar problem with WAS 5.1 and SQL Server 2000. The SQLException has a nested exception that can be retrieved using the getNextException() method. This will give you some more information as to what is causing the problem. Ours seems to be triggered by a dropped connection at the SQL end. normally WAS will recover from that gracefully, but in our situation it is not.
Doug

Forte:Transaction Handling

Similar Messages

Maybe you are looking for