• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Implementing a shared cache?

 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

In my EJB application, I need to implement a shared security cache, which will be queried by session beans to determine user authorization. Can someone please shed some light on how this could be done? Also, in the future, there might be requirement to go clustering, in that case, how to manage multiple copies of caches?

Thanks,
Tong
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Tong,

In this specific case (security/authorization) you should let the container
help out. For instance by using a connection to LDAP?

In other cases we implemented a cache outside of the J2EE container, running in a separate JVM.

greetz,
Maarten
 
Tong Wang
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Maarten,

Thank you for the response. Yes, in this case, it is for user authorization. But we need one that can be easily managed/customized such that the system administrator will simple assign user access to different business entities through an administrative UI, and when user later logs into the system and calls session beans, the session beans will need to determine if the user has access on the fly. Since the authorization information is stored in DB, instead of hitting the DB every time, I thought that initially, the authorization information could be loaded from DB and cached. Maybe I am not fully understanding the J2EE declarative security, but I think you'll have to modify the deployment descriptor every time the security configuration is changed and thus will require a re-deploy. So, the declarative security will not meet my customizable requirement. Right?

Also, I am interested in the cache that is outside of the J2EE container, could you please provide some more details? Is it still running under the J2EE server? If not, how does it get managed? How does the EJB interact with the cache? What happens if multiple EJBs do read/update at the same time to the cached object? Any lock?

Best,
Tong
 
Maarten de Heus
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Tong,

With authorization the idea is that you assign EJB method permissions to groups. Your system administrator can then create new users and place them into those groups. No need to redeploy your EJB's because the groups are stable.

In the deployment descriptor of your EJB use the <method-permission> tag to tell the server which roles are allowed to call which methods. For the roles you specify groups and not specific users. You then map the groups specified in the <method-permission> tag to real groups/principals you created in your J2EE server. This mapping is not specified in the J2EE spec so how this mapping is done, depends on the specific server you are using. In Bea WebLogic the mapping is done in the WebLogic specific deployment descriptor (weblogic.xml).

As for the external cache implementation. The J2EE spec. has some demands for the bean developer about not interfering with the container. Some of those demands: No messing about with the classloaders, do not use native libraries, do not use static variables. In cases where we were asked to break those demands, we created a separate JVM running the law-breaking code. We connect to the other JVM using RMI.

Most caching mechanisms are implemented using some Singleton pattern. (static variable which is also a nono). Run the cache in a separate JVM and connect via RMI. Do NOT implement the cache yourself but use some framework like JCache. The framework will handle the multiple calls.

hope this helps...

greetz,
Maarten
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic