This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'll attempt to explain this a clearly as possible.
1) A JSP tag library that serves language localized UI objects for company Web applications.
2) Information that generates these objects is provided via the parsing of xml files read in from the local file system (via UrlClassLoader).
3) In order to minimize footprint, only one instance of the DataServer object module must be shared across all session instances (possibly thousands).
4) Object server content must be dynamically reloadable upon,
a) A configurable timer that when run sets a flag to indicate that the xml file source needs to be checked for updates during the next access.
b) next access after flag is checks a date stamp in the xml file(s) and if different then the prior access, refreshes the cache of the singleton DataServer instance.
So a typical SimpleTag process would do something like this:
(pseudo SimpleTag code):
seems simple enough... however, the obvious issue for me in this case is after the ds.getSomeObjectList() is performed and the objects are in the process of being sent to the session space and then rendered via the JSP client code in one client, another client wanting this same DataServer comes in... and during this access it is deemed necessary to reload the object cache as per the rules stated above. If this should happen the objects that the first client is processing are deleted due to the cache refresh and all hell is to be paid.
This has to be a relatively common problem with possibly many approaches to guarantee the integrity if the DataServer objects across multiple clients?
Personally I can come up with no logical solution to absolutely guarantee that at no particular time a referenced object will become unglued due to the dynamic reloading requirement.
Can anyone provide suggestions on how to approach this? Other then coming up with an elaborate access counting algorithm which would be very difficult to support, I'm at a loss as to what to do about this.
Dieter Quickfend wrote:What do you consider the problem with that object becoming detached when the cache is refreshed?
I would think somewhat obvious, but if the original object that was returned was being referenced for contained properties by client 1 and it was unexpectedly deleted by a second client process during this event wouldn't/couldn't it result in a null pointer (or some other reference exception) condition? or should the GC not allow the deletion since it's being referenced by another thread?
Joined: Jan 16, 2009
Karl Krasnowsky wrote:but if the original object that was returned was being referenced for contained properties by client 1 and it was unexpectedly deleted by a second client process during this event ...
I guess it's not technically deleted by the update process, simply replaced, so the original should still be accessible by the initial client undisturbed until its reference is released? I guess I'm looking at this as if I'm modifying the same object, but essence this isn't the case. I also think I'm using the term "guess" too much. Makes me nervous.