Just to share my experience with singletons: under heavy stress we found that a singleton class in our framework was garbage collected. As far as I remember, singletons are eligible for that with current SDKs despite policy has changed over times as I read from some document in the web.
They were eligible for GC if its ClassLoader is GCd and they are not referenced by any object... or something like that. Please check for accuracy.
:-(
It would be helpful for you if someone could agree this behavious in order to consider if this could be an issue for you.
Regards,
Adolfo.
From: Mick Wever <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Is singleton DAO acceptable? -- Best Practices Date: Tue, 26 Aug 2003 14:47:25 +0200
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]
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
