ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon Goodin <brandon.goo...@gmail.com>
Subject Re: Some IBATIS Design Issues
Date Fri, 17 Dec 2004 23:44:06 GMT
Have you used EXTERNAL transaction management? This allows for you to
decide when to commit a transaction. It becomes your responsibility to
start, commit and end transactions. See Page 5 of the DAO Developer
Guide.

Another option for more complex DAO management is the Spring framework.

Brandon


On Fri, 17 Dec 2004 23:18:55 -0000, Dibyendu Majumdar
<dibyendu@mazumdar.demon.co.uk> wrote:
> 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.
> 
> From a Client tier - the code that invokes X and Y may look like this:
> 
> X x = new X;
> Y y = new Y;
> x.doWork();
> y.doWork();
> 
> So far the code looks similar to the JPetStore example - our X and Y classes
> are like the "Service" classes in JPetStore.
> 
> The problem starts if we do not want X and Y to commit or rollback - because
> we need the Client tier to decide when to commit or rollback. Remember that
> the Client tier knows nothing about the DAO layer. To commit therefore the
> Client tier must use a UserTransaction object like this:
> 
> UserTransaction ut = new UserTransaction();
> ut.begin();
> X x = get new X;
> Y y = get new Y;
> x.doWork();
> y.doWork();
> ut.commit;
> 
> But this won't work because IBATIS will attempt to commit inside
> DaoManager.commitTransaction().
> 
> We think that when a Global Transaction (JTA) is being used, IBATIS should
> only manage Connections and not attempt to perform transactions. The whole
> idea of JTA is that it is the "Client" that decides when to commit - the
> application tier cannot make that decision. Since all access to DaoManager
> is within the application tier - it follows from this that DaoManager must
> not attempt to manipulate a UserTransaction object.
> 
> IBATIS treats JTA and JDBC as separate mechanisms - but the fact is that
> even with JTA, JDBC Connections are used. Hence, from the DAO perspective,
> the code for DAO that uses JDBC looks the same as that which uses JTA.
> 
> We therefore think that this separation is incorrect - we only need one kind
> of DaoManager - a JDBC one. To support Global Transactions, all that is
> required is a flag that says - do not commit or rollback using the
> connection object - assume commits ae handled elsewhere.
> 
> We have worked around this problem by replacing the IBATIS transaction
> classes with our own. In the example configuration and classes I am
> attaching, you will see that the same DAO classes are switched from JDBC to
> JTA/XA without any change in the type of Transaction Manager.  Only the
> DataSource is changed, and a flag (globalCommit) is set.
> 
> The other change we have made is that we do not assume that a DataSource
> will be obtained from JNDI in a JTA environment - instead we use a Factory
> class which is responsible for creating a DataSource. The factory class may
> or may not obtain the datasource from JNDI.
> 
> I do not know if I have been able to explain the "problem" or the
> "solution". To summarise, what I am saying is:
> 
> a) IBATIS should not manipulate UserTransaction objects.
> b) The difference between JTA and JDBC is a spurious one - only one type is
> required. Only the type of DataSource needs to be changed to switch from one
> to the other, and some intelligence that switches "off" local
> commits/rollbacks. In our case, we use a flag called "globalCommit" - if set
> to "true" (in JTA mode), this means that the DAO layer must not commit or
> rollback.
> 
> You will also notice in the example that we use SqlMap in one DAO Context
> and plain JDBC in the other. For SqlMap implementation, we would have liked
> to push the DataSource/globalCommit settings from dao-config.xml - but
> IBATIS doesn't allow that. So we have had to setup these in the SqlMap
> config file.
> 
> I should like to hear your views.
> 
> Thanks and Regards
> 
> Dibyendu
> 
> 
>

Mime
View raw message