>>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.
for some versions type of class loader affects is it eligible for GC, to prevent singelatons eligible for GC you can use struts plugin feature, initialize all singletons and add references for each inside one object , bind object to Servlet Context, in that case these singletons will be never GC -----Original Message----- From: Adolfo Miguelez [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 11:10 PM To: [EMAIL PROTECTED] Subject: Re: Is singleton DAO acceptable? -- Best Practices 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
