Re: replacement for useBean directive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonathan, Jonathan Mast wrote: > class BeanBag { > private static AppleBean appleBean = null; > private static BananaBean bananaBean = null; > > public static AppleBean getAppleBean() { Might I recommend that you use a "regular" class instead of one with static members and methods? I think you'll find it more flexible (for instance, you will be able to extend the class and replace the object in memory with the extended class, or you could wrap one object in another, etc., neither of which are possible with static methods). You could just create a new instance of this class (BeanBag) at app startup and toss it into the application scope. > In the Servlet code, I just obtain a bean like this: > AppleBean appleBean = BeanBag.getAppleBean(); It would be a bit more complicated, but your new code would be: BeanBag bb = (BeanBag)application.getAttribute("my.package.beanBag"); AppleBean appleBean = bb.getAppleBean(); If you're feeling sassy, you could implement a getAppleBean() method in a superclass from which all of your servlets extend, and clean up your code a little bit more. Tres' objectique! > My question is: where (or if) should I implement the synchronization? Synchronize the methods of your BeanBag class (whether static or not). > But wouldn't making the methods in BeanBag synchronized be a better > approach? In the example, the bean in question was an application-scoped bean, which requires synchronization in the generated Java code itself (because there is a null check for the reference and the possibility of creating a new object and inserting it into the application scope). Your solution will have a single object in the application scope (or will be a static singleton) and therefore the synchronization can be handled locally (in the class). Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklufdIACgkQ9CaO5/Lv0PDV1ACfQMCD60vazQTz5xhJeRd8mCbh rdIAnigXjKQ+z7XDFWC6jLdBUI79wzPh =Vipb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: replacement for useBean directive
> From: Jonathan Mast [mailto:jhmast.develo...@gmail.com] > Subject: Re: replacement for useBean directive > > do I really need synchronization at all? Short answer: yes. > Is synchronization really called for here, either > around the getITEM() methods inside the beans or > around the methods in BeanBag that return the > bean? Yes to both. Your example getApple() shows use of some form of Map, most forms of which require external synchronization. Even if such Map objects implemented internal synchronization, the logic that checks for the existence of the key then retrieves the corresponding value requires that the state of the Map not change between the containsKey() and get() calls. BTW, you're creating a ton of throw-away objects by doing String.valueOf(int) here; you may be better off to keep appleID as a String or Integer throughout. Also, you don't need the containsKey() call, the get() will return null if the key isn't present. synchronized Apple getApple(int appleID) { purgeIfTimeout(); //calls appleMap.clear() if we've timed out Apple a = (Apple)appleMap.get(String.valueOf(appleID)); if (a != null) return a; a = FruitDB.getApple(appleID); if (a != null) appleMap.put(String.valueOf(appleID), a); return a; } Also, your appleMap should be declared as HashMap or HashMap (or whatever Map type you're using) so you can get rid of the casting. Your BeanBag class methods also need synchronization to close the window between testing a field for null and then allocating an object for it. Failure to do so runs the risk of two threads both seeing the field as null, and both creating beans for the same item type. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: replacement for useBean directive
Thanks Chuck, just one more question: do I really need synchronization at all? These Beans basically work like this: getApple(int appleID) { purgeIfTimeout(); //calls appleMap.clear() if we've timed out if (appleMap.containsKey(String.valueOf(appleID)) { return (Apple)appleMap.get(String.valueOf(appleID); } else { Apple a = FruitDB.getApple(appleID); //this is where the database interaction takes place if (a != null) appleMap.put(String.valueOf(appleID), a); return a; } } Is synchronization really called for here, either around the getITEM() methods inside the beans or around the methods in BeanBag that return the bean? On Tue, Jan 6, 2009 at 11:14 AM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Jonathan Mast [mailto:jhmast.develo...@gmail.com] > > Subject: replacement for useBean directive > > > wouldn't making the methods in BeanBag synchronized be > > a better approach? > > Definitely. Centralize the required synchronization rather than burdening > each caller with it. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
RE: replacement for useBean directive
> From: Jonathan Mast [mailto:jhmast.develo...@gmail.com] > Subject: replacement for useBean directive > wouldn't making the methods in BeanBag synchronized be > a better approach? Definitely. Centralize the required synchronization rather than burdening each caller with it. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
replacement for useBean directive
OK I know this isn't Tomcat-specific, but my post on Sun Forums didn't get much of a reply, so I thought I'd try it here. I'm in the process of translating a series of JSPs into straightout servlets and I have a question about how I should replicate the functionality of the useBean directive in my Servlet. I have a set of Beans that mediate between the JSP and a database (actually btwn JSP and a class that accesses the db). These beans cache results from the database, cutting back on back and forth traffic. They timeout after varying periods of time, flush their memory (hashmaps) and then reload as needed. I've used the useBean directive with no problem, it's just that now the project has grown in complexity to where it needs to be re-written as a set Servlets. My solution for replacing the useBean functionality has been a BeanBag class with the following form: class BeanBag { private static AppleBean appleBean = null; private static BananaBean bananaBean = null; public static AppleBean getAppleBean() { if (appleBean == null) { appleBean = new AppleBean(); } return appleBean; } . and so on } In the Servlet code, I just obtain a bean like this: AppleBean appleBean = BeanBag.getAppleBean(); My question is: where (or if) should I implement the synchronization? The generated servlets that Tomcat creates for the useBean directive uses Synchronized Statements, like this: synchronized (application) { appleBean = (com.fruitsalad.AppleBean) _jspx_page_context.getAttribute("appleBean", PageContext.APPLICATION_SCOPE); if (appleBean == null){ appleBean = new com.fruitsalad.AppleBean(); _jspx_page_context.setAttribute("appleBean", appleBean, PageContext.APPLICATION_SCOPE); } } But wouldn't making the methods in BeanBag synchronized be a better approach? Thanks