Thanks Ben,

Means I can implement something like connection / thread pool for DAO's.
And yes you are right that there is no performance by DAO caching. But just
the Factory pattern I intorduced. So that there wod be less dependency
between Beans & DAO's.

And Im not able to identify the methods of DAO which needs to be
synchropnized. Ir there any property which I need to look in to the methods
to identify.

Im calling som private methods also in DAO and passing the connection object
from one methods to another. Is there any issue in this?

Manish

-----Original Message-----
From: A mailing list for Java(tm) 2 Platform, Enterprise Edition
[mailto:J2EE-INTEREST@(protected)
Sent: Thursday, July 15, 2004 3:00 PM
To: J2EE-INTEREST@(protected)
Subject: Re: DAO's factory is right or not! URGENT


> -----Original Message-----
> From: Manish Malhotra [mailto:manish.mmalhotra@(protected)]
> Sent: 15 July 2004 10:16
> To: HILL, Ben -Syntegra UK
> Subject: RE: DAO's factory is right or not! URGENT
>
>
> Ben,
>
> We have implemented the Data Access Object pattern to access
> the interact with data base. And to get the different DAO
> objects we used DAO factory.
>
> So, my issue is that we are maintaining cache of DAO objects
> in the factory.
> And using the same object for multiple request.

You're storing the DAO in a map, but there will only be one instance of the
DAO in there - therefore you're not really adding any performance
improvement
over a regular singleton. If you make a call to getBankOverrideDAO() and the
map does not have a DAO in there, one will be instantiated and put into the
map. Each consecutive call on getBankOverrideDAO() will then return this
instance as it will be able to find it in the map. You *may* have some
threading issues with the DAO but just make sure any methods that need to be
are synchronized.

If you really wished to maintain a pool of DAOs, you'd more likely have a
list of many DAOs that you could serve out in (an example of one of may
strategies) a round-robin method. In this method, you'd create a pool of
DAOs
by instantiating them all and adding them to a list. When a request comes
in,
you would give them the "next" DAO. When you have served the next DAO, you'd
increment the pointer to point at the DAO behind that one in the list.
Again,
this is just a round-robin example. You could get much more clever and
implement load-balancing algorithms etc.

You may also wish to think about how the pool of DAOs grows and shrinks to
deal with load. You could have an initial pool size, then if that pool is
fully used, increase the pool by adding more instances in. Then, if load
decreases; shrink the DAOs again to free DB connections... There is lots to
work with...

HTH

Ben


>
> So, Is this implementation is ok with point of view PERFORMANCE.
>
> Or what I found on net for this pattern is they are creating
> new Object of DAO every time in the Factory where, Im
> creating only once and then using the same.
>
> I hope this will clear my question
>
> Thanks & Regards,
> Manish Malhotra
>
> -----Original Message-----
> From: ben.hill@(protected)]
> Sent: Thursday, July 15, 2004 2:29 PM
> To: manish.mmalhotra@(protected)
> Subject: RE: DAO's factory is right or not! URGENT
>
>
>
>
> > -----Original Message-----
> > From: Manish Malhotra [mailto:manish.mmalhotra@(protected)]
> > Sent: 15 July 2004 09:55
> > To: J2EE-INTEREST@(protected)
> > Subject: DAO's factory is right or not! URGENT
> >
> >
> > Im again sending this query because no body has replied yet. I need
> > some help as early as possible.
>
>
> What exactly are you asking?
>
> Cheers,
>
> Ben
>
>
> ********************************************************************
>
> This email may contain information which is privileged or
> confidential. If you are not the intended recipient of this
> email, please notify the sender immediately and delete it
> without reading, copying, storing, forwarding or disclosing
> its contents to any other person Thank you
>
> Check us out at http://www.btsyntegra.com
>
> ********************************************************************
>


********************************************************************

This email may contain information which is privileged or confidential. If
you are not the intended recipient of this email, please notify the sender
immediately and delete it without reading, copying, storing, forwarding or
disclosing its contents to any other person
Thank you

Check us out at http://www.btsyntegra.com

********************************************************************

===========================================================================
To unsubscribe, send email to listserv@(protected)
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected)".

===========================================================================
To unsubscribe, send email to listserv@(protected)
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected)".