Mailing-List: contact ibatis-user-java-help@incubator.apache.org; run by ezmlm
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <003201c4e48e$c79d99e0$0200000a@lan>
From: "Dibyendu Majumdar" <dibyendu@mazumdar.demon.co.uk>
To: <ibatis-user-java@incubator.apache.org>
Subject: Some IBATIS Design Issues
Date: Fri, 17 Dec 2004 23:18:55 -0000
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_002F_01C4E48E.C77C0820"

This is a multi-part message in MIME format.

------=_NextPart_000_002F_01C4E48E.C77C0820
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have been looking to use IBATIS for our DAO layer, and have feedback on
one or two design aspects. I will try to explain this as best I can - but it
will probably take a few messages before I can get this across - so please
bear with me.

Like many other folks, we are building an application framework that allows
us to build our application in layers. Broadly speaking, we have:

Presentation layer based upon Struts - I will call this the Client tier.
Application Logic (Business Logic) layer.
Database Layer - this is where we are planning to use IBATIS.

We want the Client tier to know nothing about the DAO tier. Only the
application tier knows about the DAO tier.

The reason I use the term "Client tier" is that, instead of the Presentation
tier, a client may also be a command line program, or a Job run by a
Scheduler.

The important thing for us is to ensure that the framework can work with or
without a J2EE server.

We also want to be able to run distributed transactions across two or more
databases - without making any changes to the application or DAO layer. The
idea is that the DAO layer deals with JDBC connections - and does not know
or care how the JDBC connections are obtained. A JDBC connection may be from
an ordinary datasource or from an XA datasource - it should not matter to
the DAO.

So far it must appear that there is no issue here - for IBATIS is designed
to handle this requirement. However, this is not exactly the case.

We think that the problem in IBATIS is that it mixes the "Transaction"
pattern and the "Connection" pattern into one single abstraction. A
Transaction in IBATIS is not only a mechanism for committing data, but also
for managing the Connection object.

Let me present a scenario that illustrates the kind of problem this creates.

Let us say that we have two DAO classes - A and B.
We have configured our system so that A accesses a different database from
B.

Now, we have two application level components - X and Y.
X obtains an object of type A, whereas Y obtains and object of type B.
A user of X or Y does not know that there are two databases involved. It is
not even aware of how the DAO layer works.

Within X, we have code that looks like this:

DaoManager.startTransaction();
A.dowork();
DaoManager.commitTransaction();
DaoManager.endTransaction();

The code for Y looks similar, but uses B.
------=_NextPart_000_002F_01C4E48E.C77C0820--