Mailing-List: contact ibatis-user-java-help@incubator.apache.org; run by ezmlm
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <001901c4e559$5a25e720$0200000a@lan>
From: "Dibyendu Majumdar" <dibyendu@mazumdar.demon.co.uk>
To: <cbegin@ibatis.com>
Cc: <ibatis-user-java@incubator.apache.org>
References: <003201c4e48e$c79d99e0$0200000a@lan>
 <16178eb104121808575595001b@mail.gmail.com>
Subject: Re: Some IBATIS Design Issues
Date: Sat, 18 Dec 2004 23:28:59 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Clinton,

Thanks for the detailed response. I am still learning about IBATIS
everyday - the stuff I sent was my very first attempt to work around the
problems I was facing. However, I can already see that my workaround can be
simplified - eventually I will come down to the really essential bit - and
that would be my problem statement.

> On DAO...
>
> Before I get into any of the other topics, I'll say that your
> requirements are likely too complex for iBATIS DAO (not SQL Maps).
> iBATIS DAO is a simple DAO implementation meant for 80% of the cases,
> whereas you would seem to be in the 20%.  I recommend you use a custom
> DAO framework with iBATIS SQL Maps.

I was actually working on my own DAO framework when I realised that IBATIS
DAO already had most of what I wanted - it was just a small bit that I
needed changing. Fortunately, due to the fact that the TransactionManager
can be changed, this worked for me.

In particular, I like the following about the IBATIS DAO framework :
a) It is small and simple.
b) It allows association between DAO classes and a DataSource - which is
cool.
c) I like the fact that the interface between the caller of a DAO class and
the DAO class is so opaque - the caller does not need to know how the DAO
classes work or even obtain database connections - this is also cool.

While I have a working solution, it bothers me that I am having to change
some default bevaiour - this could potentially cause future problems - for
example, if you decided to change the way the DAO framework interacts with
the TransactionManager. Ideally, I would like to use IBATIS as is, without
any changes.

I have a question - why is the EXTERNAL type in DAO different from the
EXTERNAL type in SqlMap - ie why does the former lack Connection management?
A related question is - does anyone actually use the EXTERNAL type in DAO
framework?  Also, see my proposals below regarding this.

> On JTA transaction management...
>
> If you look at the code for JtaTransaction in the SQL Maps framework,
> you'll see that there is logic there that allows a transaction to be
> externally managed by the "client".  Note the "newTransaction" field
> of the JtaTransaction class.  That tracks whether iBATIS has started
> the transaction, or if it was started externally.  iBATIS will ONLY
> begin and commit/rollback if the client has NOT.  This allows iBATIS
> code to be written in a consistent fashion, whether you're using JTA
> or not.  If this logic doesn't work for you, then like Brandon said,
> you have the option to use EXTERNAL.  Also, the TX management is a
> pluggable component of iBATIS, so you should NEVER have to change any
> of the core framework code.  You can write your own TX manager and
> configure like any of the predefined ones.
>

I have noticed what you describe. Basically, IBATIS will only
commit/rollback a UserTransaction that it has begun itself.

I still do not think that IBATIS should be touching UserTransaction objects.
Because the whole point of these is to allow the Client to manage
transactions. Do you have anyone actually using the JTA facility and relying
upon IBATIS to manage the UserTransaction objects?

But, as you say, EXTERNAL type in SqlMap does what I want ... so I don't
need to worry about the JTA transaction manager in SqlMap. DAO is another
story (see below).

> On DataSource factories and JNDI...
>
> JNDI is a standard for registration of managed resources.  I would
> recommend you use it.  We could perhaps support DataSource factories
> in the future, but I don't yet see any compelling reason why we would?
>  If you're going to write a custom DataSource Factory, why not just
> write a custom DataSource that proxies to the real DataSource
> implementation?  Why does it have to be a factory?

I think that the problem I am facing is due to the difference between how
DAO handles data sources, and how SqlMap handles them. SqlMap seems to be
more generic - ie, the datasource factory can be one of the predefined ones
or user supplied. But in case of DAO, there seems to be some rigid rules -
example:

JDBC can only use SIMPLE, DBCP or JNDI.
JTA can only use JNDI.
EXTERNAL does not support a DataSource at all.

Why not make DAO behave the same as SqlMap - ie use a DataSourceFactory -
and let it be user customisable?

-----

Now for my revised proposals:

a) Modify EXTERNAL type in DAO to match the EXTERNAL type in SqlMap - ie,
EXTERNAL should manage connections as in JDBC type, and provide a
DataSource, but commits and rollbacks should be no-ops. Also provide a
DaoTemplate for EXTERNAL type (although, JdbcDaoTemplate would also work
fine).

b) Make DataSource management in DAO framework factory based as it is in
SqlMap - and let it be user customisable regardless of the transaction
manager type (as in SqlMap).

Regards

Dibyendu