ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: Some IBATIS Design Issues
Date Sun, 19 Dec 2004 07:22:33 GMT
>> a) Modify EXTERNAL type in DAO to match the EXTERNAL type in SqlMap 

DAO and SQL Maps are very different frameworks, with very different
purposes. There is no reason that their behaviour should "match".  I
think that by comparing these frameworks, you're getting confused. 
Don't try to draw parallels between them.

>> Also provide a DaoTemplate for EXTERNAL 

The templates are intended to wrap an implementation specific
transaction.  By its very definition, EXTERNAL doesn't have a known
transaction implementation.  So a template for EXTERNAL doesn't make
any sense at all.

>> EXTERNAL should manage connections as in JDBC type

No it shouldn't.  In the case of the DAO framework (which is a generic
framework), EXTERNAL means that there is no known or controllable
transaction manager at all, or its managed "externally".  In the case
of SQL Maps (which is a JDBC framework), EXTERNAL simply means that
you'll start and stop transactions yourself....but SQL Maps always
needs a DataSource (hence the separate configurations).


>> b) Make DataSource management in DAO framework 
>> factory based as it is in SqlMap 

I don't see how this would help you.  The factory is not a public API
in SQL Maps and it wouldnt' be in DAO either.

By definition, an iBATIS DAO implementation binds a transactional
management facility (Connection, UserTransaction), with a persistence
facility (SqlMaps, Hibernate, JDBC) and some persistent resource
(database, flat file etc.).  Each DAO transaction manager
implementation binds these three things together and allows them to be
configured.  That's the design choice for iBATIS DAO, and it works for
many people.  I often recommend that people with more complex
requirements build their own.  In fact, *I* often build custom DAO
implementations for clients instead of using iBATIS DAO.

Use it if it works for you.  If it doesn't, write your own.  It's
usually only about 500 lines of code!

Cheers,
Clinton


On Sat, 18 Dec 2004 23:28:59 -0000, Dibyendu Majumdar
<dibyendu@mazumdar.demon.co.uk> wrote:
> 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
> 
>

Mime
View raw message