On Mon, 25 Aug 2003 16:32:07 +0200, Federico Real wrote:
> Hi Mick, I like your implementation od DAO , Can you send me a example for
> this? I would like use it.
> ----- Original Message -----
> From: "Robert Taylor" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Monday, August 25, 2003 3:07 PM
> Subject: RE: Is singleton DAO acceptable? -- Best Practices
> The design pattern doesn't states how DAO's are to be implemented, but
> rather what problem they are supposed to solve.
>
> One reason why you might not want a DAO to be a singleton is if you
> instantiate
> one with an Connection. This might be done to avoid having to pass the
> Connection
> to each method.
>
> I think your implementation is appropriate. It makes sense performance wise
> and it
> is also intuitively more OO. Why create a new instance of an object if it
> does
> not maintain state?
>> -----Original Message-----
>> From: news [mailto:[EMAIL PROTECTED] Behalf Of Mick Wever
>> Sent: Sunday, August 24, 2003 12:59 PM
>> To: [EMAIL PROTECTED]
>> Subject: Is singleton DAO acceptable? -- Best Practices
>>
>> All the DAO examples I've read have DaoFactory classes that always return
>> a new DAO instance, and typically the action using it keeps a handle to it
>> for that session.
>>
>> The DAOs that I've created have no state or instance variables, and get
>> their connections from a synchronized pool (and always returning the
>> connection within the same method call). So, since they are
>> multi-threaded, it makes sense to me performance wise it is better
>> for the factory to always return a singleton instance of the DAO.
>> This single instance of the DAO is shared across all sessions in
>> the JVM.
>> (Note this is not the traditional usage of singleton where the singleton
>> itself is responsible for returning the single instance through a static
>> method).
>>
>> My question is, is this such a good idea? Am I missing or misunderstanding
>> something crucial about the DAO Design Pattern?
Sorry the code is not open-source.
But the basic idea is if your DAO is multi-thread capable, ie it does not
have instance variables, or acesses all instance variables in a
synchronized manner, then your DAOFactory can return the same instance all
the time.
For example:
where you would have (in your DAOFactory):
<pre>
public static MyDAO getMyDAO() throws MyDAOException{
return new MyDAOImpl(); // OR however you choose to plug in the chosen
implementation
}
</pre>
instead you would have:
<pre>
private static MyDAO instance;
public static MyDAO getMyDAO() throws MyDAOException{
if( instance == null){ // of course you need to synchronize this or make
instance violatile
instance = new MyDAOImpl(); // OR however you choose to plug in the chosen
implementation
}
return instance;
}
</pre>
Infact I have a SuperDAOFactory that all my DAOFactory subclass and
it has a method that finds the DAOImpl I will use given the DAO interface
being requested from JNDI. Then all my instances are stored in the SuperDAOFactory
inside a Hashtable. (This solves the synchronization on the instance variable above).
Mick.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
