That's what I do :). The only thing you might need to worry about is that the data in the security table changes after you load up the hash map. What I usually do is if the user is not found I reload the map and try one more time.
Regards, _____________ Robert Moskal Most Media Brooklyn, USA -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Stephen Davidson Sent: Thursday, March 07, 2002 7:12 AM To: Orion-Interest Subject: Re: Caching Group Information Christian, Joanne wrote: > Hi All, > > I am using a custom user manager that gets group and user information from > the database. I would like to cache the database information when the user > manager is initialized; and access the cache to get the user information. > > Can anyone suggest the best method for doing this? I am thinking about > using a hashmap, but I'm not quite sure what is the best option. > > > Thanks, > > Joanne > > > Hi Joanne. I am using an Entity EJB, and letting the Container worry about how to handle the cache. My UserEJB actually loads itself from several tables, and has two hashmaps and some rather complex objects. Of course, this has to be done using BeanManaged Persistance, but actually works quite smoothly. Among other things, this is key to how the security model for my application works. In the EJB specs, there is a method called getHandle(), which returns a small, serializable object, that can be passed around and/or stored in Hashmaps or other objects. It can be used to obtain a remote interface to a specific EJB w/o having to do a home lookup and a findByXXX call. (userHandle.getEJBObject does the trick). With this method, if the EJB is being used, container keeps it around. If/when not being used, container releases it (supposedly). And as this is handled by the container, you do not have to write the code to load/release the user data. And this method is also expandable into a cluster (only one instance of Entity EJB per cluster, + backup copies, with cluster worrying about how to keep data syncronized, not you). -Steve -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208
