Browse Prior Art Database

Auto Re-try EJB Transaction Logic on J2EE Enabled Distributed System

IP.com Disclosure Number: IPCOM000015844D
Original Publication Date: 2002-Aug-01
Included in the Prior Art Database: 2003-Jun-21
Document File: 4 page(s) / 38K

Publishing Venue

IBM

Abstract

[What kind of problem does this idea try to solve?]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 4

Auto Re-try EJB Transaction Logic on J2EE Enabled Distributed System

[What kind of problem does this idea try to solve?]

The some failures which occur at back end systems may not be permanent
failures on the J2EE (Java 2 Enterprise Edition) enabled EJB (Enterprise Java
Beans) distribution transaction system. For example, there are DeadLock,
LockWaitTimeout caused by a resource competition on the database system or a
temporary network failure.

Although it is dependent on a DBMS (DataBase Management System) implementation
by a database vender, most DBMS venders provide the function of a DeadLock
detection which detects a deadlock situation and forces to terminate one of
the competing two threads. In this case, a user can avoid a DeadLock failure
automatically by re-trying the transaction which the terminated thread
executed. And it was judged as the permanent failure if it is unsuccessful to
re-try the transaction two or more times.

However, if it does re-try the transaction simply when a server side failure
is detected, it has the possibility that the inconsistency of the business
data occurs by the timing when a server side failure occurred in the flow of a
business logic.

As for business data to say here, it means both of the persistent business
data stored by a XA resource manager such as a database, and the transient
business data which a business logic uses in memory. The transient business
data contains an instance variable of the class implementing a business logic
and arguments from a client.

This invention is the realization method which re-tries a transaction
automatically after detecting server side failure, and guarantees the perfect
consistency of both persistent and transient business data. The advantage over
the other company can be found out by offering this as the function of a J2EE
application server product or as parts of a J2EE application framework.

[Do you solve the above problem with what kind of means or the method?]

<Preconditions>

An EJB StatefulSessionBean which implements a business logic is written with (SF).


1.


2.


3.


4.


5.

User --> EJBClient --> SL --> SF --> XA Resource Manager (ex. DBMS)

<Problem-1>
When to re-try the transaction automatically in face of a server side failure, it has
the possibility that a business logic has changed the request from a user. We must
save a initial state of a user request and restore it before re-trying a transaction.

<Solution-1>
An EJBClient delivers a request object as an argument of the invokeSL(UserRequest
ureq) method of SL. First of all SL makes the copy of UserRequest object. It is out of
scope about the way of making the copy of Java object because it is common knowledge
how to make a copy using java.lang.Cloneable or java.io.Serializable interface. SL
always use the copy of UserRequest object to call invokeSF() method which a business

1

A user develops a business logic within invokeSF() method of the SF.
An EJB StatelessSessionBean which controls a transaction is written with (SL).

A SL...