I know there are some limitations related to transactions when using the DB2 JDBC drivers on z/OS, so perhaps this is part of the problem you've encountered. For example, with WebLogic Server you can't use XA transactions via JTA unless you make your connection through a DB2 driver on AIX, Linux or Windows. Here is the following quote from our online docs at http://edocs.bea.com/wls/docs81/jdbc_drivers/db2.html#1057189:
To use JDBC distributed transactions through JTA with the DB2 driver, DB2 UDB 8.1 for Windows, UNIX, or Linux is required. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, July 23, 2004 4:29 PM To: [EMAIL PROTECTED] Subject: Re: [Juglist] Java and DB2 Transactions That=B9s a long topic :-). I can't say what the semantics of this are likely to be so far as any transaction automation if its not a bean. I don't know enough about the APIs provided outside of J2EE in WebSphere 3.5. I can say that it is quite possible that they apply declarative transaction models to them since IIRC the Java transaction stuff came out of IBM (could be wrong)= . Upgrading to WebSphere 5.0 would bring you up to a J2EE compliant release. Its likely that you'll have to make some code changes to make your application utilize J2EE APIs. Since I work for JBoss, I ought point out that you can of course expend tha= t effort towards JBoss 3.2 or even 4.0 and cut your license costs of course. -Andy > From: "Cohen, Meg" <[EMAIL PROTECTED]> > Reply-To: "Research Triangle Java User's Group mailing > list."<[EMAIL PROTECTED]> > Date: Fri, 23 Jul 2004 11:48:33 -0400 > To: "'Research Triangle Java User's Group mailing list.'" > <[EMAIL PROTECTED] .org> > Subject: RE: [Juglist] Java and DB2 Transactions >=20 > Nope, it's not a bean at this point. Should it be? >=20 > We're trying to get off of 3.5, but it's about 3rd on our Tech. >Services group's priority list right now, after bringing up a new >mainframe and moving our data center! Last I heard we're slated to be >on 5.0 sometime this fall. Do you think that would make a difference >in this instance? =20 Thanks, > Meg Cohen > Applications Analyst Programmer > Information Services Division > UNC Health Care System > voice: (919) 966-7605 / fax: (919) 966-2110 > mailto:[EMAIL PROTECTED] > ----------------------------------------------------------------------- > In accordance with UNC Health Care System > Policy the opinion(s) expressed in this document > do not necessarily represent the opinion(s) of > UNC Health Care System or its management > ----------------------------------------------------------------------- >=20 >=20 >=20 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, July 23, 2004 11:43 AM > To: [EMAIL PROTECTED] > Subject: Re: [Juglist] Java and DB2 Transactions >=20 >=20 > Is this part of a EJB/session bean? >=20 > If so, do you have it set to Bean for the transaction-type in the > ejb-jar.xml or Container? If you have it set to container managed > transactions and do not specify a transaction attribute, one could presum= e > that it would be "Required". >=20 > I'd really recommend upgrading from WS 3.5 at this point. >=20 > -andy >=20 >> From: "Cohen, Meg" <[EMAIL PROTECTED]> >> Reply-To: "Research Triangle Java User's Group mailing >>list."<[EMAIL PROTECTED]> >> Date: Fri, 23 Jul 2004 11:14:01 -0400 >> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> >> Subject: [Juglist] Java and DB2 Transactions >>=20 >> We have a daemon running on WebSphere version 3.5 against DB2 for >>OS/39= 0 >> version 7.1.1. WebSphere and DB2 both run on an OS/390 mainframe, >> and t= he >> code for the daemon is deployed on the mainframe as well. This >> daemon i= s >> basically an event notification process. It reads records from a DB2 > table, >> processes them, and then inserts the processed record into a log >> table a= nd >> deletes it from the first table. >>=20 >> We're trying to execute two separate direct SQL calls as a single >>transaction. The class that makes the call inherits from a parent >>class which takes care of getting the database connection, setting >>AutoCommit = to >> false, and then either committing or rolling back the transaction, >>explicitly. =20 >> The code in the parent class that creates the connection and handles the >> commit or rollback is: >> Connection con =3D null; >> Vector result =3D null; >> boolean success=3Dfalse; >> try >> { >>=20 >> con=3DConnectionManager.getConnectionManager().getConnection(); >> con.setAutoCommit(false); >> result =3D callSP(con, param); >> success=3Dtrue; >> return result; >> } >> finally >> { >> try >> { >> if (con !=3D null) >> { >> if (success) >> { >> con.commit(); >> } >> else >> { >> con.rollback(); >> } >> ConnectionManager.leaveConnection(con); >> } >> } >> catch (SQLException e) >> { >> } >> } >>=20 >> callSP is an abstract method in the parent. In this case, the child cla= ss >> implements callSP method with the the following code: >>=20 >> try=20 >> { >> sql =3D "INSERT INTO TABLE1 (CFK_EVENT_TYPE_ID, CPK_EVENT_ID, " + >> "C_TS, CFK_USERID, CFK_PHYNO, CFK_MRNO, " + >> "C_KEY_01_VALUE, C_KEY_02_VALUE, C_KEY_03_VALUE, >> C_KEY_04_VALUE, " + >> "C_KEY_05_VALUE, C_KEY_06_VALUE, C_KEY_07_VALUE, >> C_KEY_08_VALUE, " + >> "C_KEY_09_VALUE, C_KEY_10_VALUE, C_KEY_11_VALUE, >> C_KEY_12_VALUE, " + >> "C_KEY_13_VALUE, C_KEY_14_VALUE, C_KEY_15_VALUE, >> C_KEY_16_VALUE) " + >> "SELECT CFK_EVENT_TYPE_ID, CPK_EVENT_ID, " + >> "C_TS, CFK_USERID, CFK_PHYNO, CFK_MRNO, " + >> "C_KEY_01_VALUE, C_KEY_02_VALUE, C_KEY_03_VALUE, >> C_KEY_04_VALUE, " + >> "C_KEY_05_VALUE, C_KEY_06_VALUE, C_KEY_07_VALUE, >> C_KEY_08_VALUE, " + >> "C_KEY_09_VALUE, C_KEY_10_VALUE, C_KEY_11_VALUE, >> C_KEY_12_VALUE, " + >> "C_KEY_13_VALUE, C_KEY_14_VALUE, C_KEY_15_VALUE, >> C_KEY_16_VALUE " + >> "FROM TABLE2 " + >> "WHERE CPK_EVENT_ID =3D ?"; >> st1 =3D con.prepareStatement(sql); >> st1.setInt(1, eventID.intValue()); >> st1.execute(); >>=20 >> sql =3D "DELETE FROM TABLE2 " + >> "WHERE CPK_EVENT_ID =3D ?"; >> =20 >> st2 =3D con.prepareStatement(sql); >> st2.setInt(1, eventID.intValue()); >> st2.execute(); >> } >> finally=20 >> { >> if(st1!=3Dnull) st1.close(); >> if(st2!=3Dnull) st2.close(); >> } >>=20 >> Because we have AutoCommit set to false, we were under the assumption th= at >> these two SQL calls would be treated as a single logical unit of >> work, a= nd >> would either both be committed or both be rolled back. What we're >> seein= g >> happen, though, is occasionally the record will be inserted into >> TABLE1 > and >> not delete into TABLE2. This causes issues because this code is part >> of > an >> event notification system which reads from TABLE2, processes a >> record, > then >> inserts into TABLE1 and deletes from TABLE2. There's a unique index >> on TABLE1, so that if the record doesn't get deleted from TABLE2, it >> will b= e >> processed a second time, but the insert to TABLE1 will fail, which >> cause= s >> the entire daemon to come to a screeching halt. >>=20 >> This only happens occasionally, but seems to always happen when we've >>brought WebSphere down. It does not happen, though, everytime we >>bring = it >> down. >>=20 >> We've tried to re-create this scenario using the WebSphere Test > Environment >> in Visual Age for Java. Basically, in our tests, we've stepped >> through > the >> code until the first SQL call has executed, and then stoped the >> WebSpher= e >> Test Environment. When we go look at DB2, the record has NOT been > inserted >> into DB2, which is what we expect to happen. Obviously, though, >> somethi= ng >> different is happening once the code is deployed to the mainframe. >>=20 Has anyone tried anything similar to this? If so, did you >>encounter the= se >> problems? Is there a something other than setting AutoCommit to >> false > that >> we need to be doing in the code? >>=20 >> Thanks, >> Meg Cohen >> Applications Analyst Programmer >> Information Services Division >> UNC Health Care System >> voice: (919) 966-7605 / fax: (919) 966-2110 >>mailto:[EMAIL PROTECTED] >> >>---------------------------------------------------------------------- - >> In accordance with UNC Health Care System >> Policy the opinion(s) expressed in this document >> do not necessarily represent the opinion(s) of >> UNC Health Care System or its management >> ----------------------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Juglist mailing list >> [EMAIL PROTECTED] >> http://trijug.org/mailman/listinfo/juglist_trijug.org >=20 >=20 > _______________________________________________ > Juglist mailing list > [EMAIL PROTECTED] >http://trijug.org/mailman/listinfo/juglist_trijug.org >=20 >=20 > _______________________________________________ > Juglist mailing list > [EMAIL PROTECTED] >http://trijug.org/mailman/listinfo/juglist_trijug.org _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
