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

Reply via email to