Multiple ejb jars and singleton DAOManager

[Mr Li <ko...@yahoo.com>]

Hi,



I'm currently assigned to a large project that requires individual ejb modularity.

In this case, its a standard app->service(sessionEJB)->db(ibatis) design.

The problem with this, is that different people will work on different service ejbs and the boss wanted seperate DaoManager(dao.xmls) for each service. 

Well, this design should work perfectly for CMP as the datasource is assigned by the container during deployment, but for ibatis this would mean a different daomanager for each service which would make it very error prone, although it uses a 'pre-agreed' jndi datasource.

But practically, this would mean multiple daomanager for single datebase app and jndi name could very well change right? The potential datasource misconfigure disaster is what I'm afraid... :)



Forcing a single daomanager singleton design would break this 'ejb modularity concept' and would create bloated dao.xml and sqlmapconfig.xml files my boss says...



Anyway, is there any global-dao.xml where one could be use to assemble multiple dao.xml as one?



Any advice?



regards,

stanley

Re: Multiple ejb jars and singleton DAOManager

[Larry Meadors <lm...@apache.org>]

Is now a bad time to tell you that the DAO part of the framework is
being deprecated?

Larry


On 11/5/06, Mr Li <ko...@yahoo.com> wrote:
> Hi,
>
>
>
> I'm currently assigned to a large project that requires individual ejb modularity.
>
> In this case, its a standard app->service(sessionEJB)->db(ibatis) design.
>
> The problem with this, is that different people will work on different service ejbs and the boss wanted seperate DaoManager(dao.xmls) for each service.
>
> Well, this design should work perfectly for CMP as the datasource is assigned by the container during deployment, but for ibatis this would mean a different daomanager for each service which would make it very error prone, although it uses a 'pre-agreed' jndi datasource.
>
> But practically, this would mean multiple daomanager for single datebase app and jndi name could very well change right? The potential datasource misconfigure disaster is what I'm afraid... :)
>
>
>
> Forcing a single daomanager singleton design would break this 'ejb modularity concept' and would create bloated dao.xml and sqlmapconfig.xml files my boss says...
>
>
>
> Anyway, is there any global-dao.xml where one could be use to assemble multiple dao.xml as one?
>
>
>
> Any advice?
>
>
>
> regards,
>
> stanley
>
>
>
>
>
>

Re: Multiple ejb jars and singleton DAOManager

[Clinton Begin <cl...@gmail.com>]

Hello,

Okay.  A few things here.

First and formost, I recommend that you don't use a DAO framework.  Use the
DAO pattern, but you don't need a framework.  Since you're using session
beans, you are likely using transactions demarcated by your EJB container.
The biggest advantage of the iBATIS DAO framework is how it simplifies
transaction management.  So because you're using both EJB and DAO, the DAO
framework is really doing nothing for you.  Sure it keeps a nice
interface/implementation separation, but I'd argue that that's possibly
unecessary but at the very least it's easily acheived without a framework.

So to summarize my first recommendation:  Ditch the iBATIS DAO framework.
It's likely not needed in your situation.  If you decide to keep running
with it...keep reading.

>> but for ibatis this would mean a different daomanager for each service
which would make it very error prone,
>> although it uses a 'pre-agreed' jndi datasource.

I disagree somewhat.  It won't be any more error prone than any other part
of your code.  In my opinion you should have a separate DAO manager for each
module, otherwise you're only partially separating the concerns of your EJB
modules -- which may be missing the point.  If you want to keep central
configuration to avoid inconsistencies in things like the JNDI datasource
name, then you can do so by using a shared property file.  Something as
simple as using a common source repository for configuration would resolve
this.

The iBATIS DAO framework is a logical abstraction layer used to hopefully
improve the quality of your code.  It's not huge infrastructure that you
need to worry about running in multiple places.

Second recommendation:  Let each EJB module use its own DaoManager, but use
a shared configuration (properties) file.

>> But practically, this would mean multiple daomanager for single datebase
app and jndi name could very well change right?

And if it changes....change the one shared property file and everything will
work fine.

I think you're doing all the right things.  Don't over-think it.  Use a
simple solution.

>> RE: Deprecation...

As larry said, the DAO framework has been deprecated.  This means that while
the DAO framework will still be available, we're not doing any more work on
it,  and we're recommending a different solution (Spring DAO) from now on.

However, if you do like the framework and intend to keep on using it, you
should feel comfortable doing so.  The source is available and it's really
not that much code.  So you could easily integrate the iBATIS DAO source
into your application and make whatever changes you need to implement your
multiple EJB needs.

NOTE:  Please don't confuse iBATIS DAO and iBATIS SQL Maps.  Only the DAO
framework is being deprecated.  The iBATIS SQL Mapper (i.e. DataMapper) is
still being actively developed and supported.

Hope that helps.

Clinton

On 11/5/06, Mr Li <ko...@yahoo.com> wrote:
>
> Hi,
>
>
>
> I'm currently assigned to a large project that requires individual ejb
> modularity.
>
> In this case, its a standard app->service(sessionEJB)->db(ibatis) design.
>
> The problem with this, is that different people will work on different
> service ejbs and the boss wanted seperate DaoManager(dao.xmls) for each
> service.
>
> Well, this design should work perfectly for CMP as the datasource is
> assigned by the container during deployment, but for ibatis this would mean
> a different daomanager for each service which would make it very error
> prone, although it uses a 'pre-agreed' jndi datasource.
>
> But practically, this would mean multiple daomanager for single datebase
> app and jndi name could very well change right? The potential datasource
> misconfigure disaster is what I'm afraid... :)
>
>
>
> Forcing a single daomanager singleton design would break this 'ejb
> modularity concept' and would create bloated dao.xml and sqlmapconfig.xmlfiles my boss says...
>
>
>
> Anyway, is there any global-dao.xml where one could be use to assemble
> multiple dao.xml as one?
>
>
>
> Any advice?
>
>
>
> regards,
>
> stanley
>
>
>
>
>
>