| View previous topic :: View next topic |
| Author |
Message |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
 Posted: Sun Jul 11, 2004 11:50 am Post subject: |
 |
|
| pragma wrote: | | The documentation in the source uses a contrived cache implementation to illustrate the usefulness of a reentrant read/write lock with writer preference (ReentrantWriterPreferenceReadWriteLock). This way, threads only block one another from reading the cache if it is being modified. |
Excelllent! Doug Lea (and Ben/Mike) to the rescue 
| pragma wrote: | I wouldn't know, for the life of me, where to begin making suggestions for a network-distributed cache design. The more I work inside this problem domain, the more I find that I need to learn.
However, google turned up this link with a whole shload of existing Java distributed-cache projects. I've already learned a few things by clicking around in here: Java/OSS Distributed Cache Solutions
|
Cool ~ thanks for that. I have a distributed cache pretty much in place, but want to ensure whatever the local cache interface turns out to be maps to it logically and semantically. I may be able to just use the read/write lock on the current local cache design as you point out.
| pragma wrote: | If the ServletProvider were to have a pluggable SessionProvider that would pave the way for all kinds of sessions quite easily. The SessionProvider could be further be pluggable by a Mango conduit for persistence/distribution. Such a pluggable conduit could also accept any conduit used for the client; this could allow cookies to work among other things.  |
That's the general idea, and why there's no session support at all right now. I'll likely setup a few alternate session wrappers, and base the session itself on the IReadable/IWritable interfaces only. Session is a quick and easy introduction to the value (and pitfalls) of a distributed cache.
| pragma wrote: | | At first, I thought it would be cake to just throw a new Dictionary instance in. But, take a look at ServletContext. The configuration and attribute dictionaries are both encapsulated as private, so there's no way a subclass could ever assign a new dictionary to either. |
There's a tricky bit here, since I'd rather not expose the ServletContext dictionary for any old servlet to mangle per its own desires. Some might argue that the environment is "controlled" and therefore one shouldn't worry about such rogue servlets. I'm more concerened from a maintenance standpoint, since these contexts are rather like global variables ~ I feel it's better to make them read-only. Had intended to make a (immutable) Dictionary plus a MutableDictionary derivative. But that doesn't help you at all. Any ideas? |
|
| Back to top |
|
 |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sun Jul 11, 2004 8:33 pm Post subject: |
|
|
| pragma wrote: | | At first, I thought it would be cake to just throw a new Dictionary instance in. But, take a look at ServletContext. The configuration and attribute dictionaries are both encapsulated as private, so there's no way a subclass could ever assign a new dictionary to either. |
How about if there were a protected ServletContext method to switch the Dictionary? At least it would still be protected for the most part, but if you're subclassing ServletContext then you can effectively do what you like ... if that works, then I'd probably make the default Dictionary immutable (sans put/remove methods), and add a MutableDictionary derivative (with put, remove, clear/reset etc).
Would that work? |
|
| Back to top |
|
|
pragma
Joined: 28 May 2004
Posts: 607
Location: Washington, DC
|
| Posted: Mon Jul 12, 2004 8:50 am Post subject: |
|
|
| kris wrote: |
How about if there were a protected ServletContext method to switch the Dictionary? At least it would still be protected for the most part, but if you're subclassing ServletContext then you can effectively do what you like ... if that works, then I'd probably make the default Dictionary immutable (sans put/remove methods), and add a MutableDictionary derivative (with put, remove, clear/reset etc).
Would that work? |
It just seems like the most balanced approach: keep the encapsulation and protection while keeping the class extensible... within certain limitations.
Then I got to thinking....
The only thing that concerns me past this point, is keeping changes to the context coordinated as not to disrupt any given request using the context. An apology may be in order here, as your original design cleary serves this purpose (accept for the ability to put/remove dictionary data from outside the class).
Perhaps I was a bit hasty in my design by subclassing ServletContext in this fashion?  Maybe it should stay read-only, and the ServletProvider should coordinate rebuilding contexts as needed per configuration changes?
_________________
-- !Eric.t.Anderton at gmail |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Jul 12, 2004 11:18 am Post subject: |
|
|
True. This is why a Servlet has to ask for the dictionary first, rather than just call a bunch of mutator methods within its context: that way, you can synchronize the swizzling of the entire dictionary, but not the individual updates.
I'm guessing this is probably enough for what you need; a synchronized protected method to switch the context dictionary, and a synchronized public methods for a servlet to retreive it. You get to swap in a MutableDictionary after the appropriate manipulations, and the servlet gets back an ImmutableDictionary base-class. Yay? Nay?
- Kris |
|
| Back to top |
|
|
pragma
Joined: 28 May 2004
Posts: 607
Location: Washington, DC
|
| Posted: Mon Jul 12, 2004 11:51 am Post subject: |
|
|
| kris wrote: |
I'm guessing this is probably enough for what you need; a synchronized protected method to switch the context dictionary, and a synchronized public methods for a servlet to retreive it. You get to swap in a MutableDictionary after the appropriate manipulations, and the servlet gets back an ImmutableDictionary base-class. Yay? Nay?
|
Yay!
That'll do just fine Kris. I'll be on the lookout for further spots to strengthen Mango.
_________________
-- !Eric.t.Anderton at gmail |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Jul 12, 2004 12:08 pm Post subject: |
|
|
| Done. Thanks Eric. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Aug 04, 2004 12:16 am Post subject: |
|
|
| pragma wrote: | | kris wrote: | | Mango.cache could use a good hashmap implementation; once that explicitly supports concurrent reading whilst writing (many of the former, only one of the latter). |
Personally, I feel that there should be a read/write locked cache or one that uses a writer-preference read/write lock rather than just a 'synchronized' cache. It would be a big boon for heavily multithreaded apps that spend more time sifting through the cache than making changes to it. |
Done.
The cache package now uses a stripped-down version of Doug Lea's latest and greatest ConcurrentHashMap (the open-source implementation). Read operations almost never get blocked, while write/remove operations are blocked only within the same hash-segment: you can specify how many segments/concurrent-changes you wish to support as part of the constructor. Doug Lea really is the man when it comes to this stuff.
Also replaced the standard D hash-function with one by Bob Jenkins. It is almost as fast, but has far greater dispersion, and therefore much less chance of collisions. The standard D one exhibits significant "funnelling". Bob's jhash (as it is starting to become known as) is faster than an FNV function and apparently produces less noise in the upper bits (on a P4, the FNV would probably be faster since that device has a comparatively slow barrel-shifter).
Finally, a head's up that the ICache interface had to change. It's been split into ICache and IMutableCache (where the former is immutable, not the latter). Any cache instance you had that uses extract() or put() will have to be changed to an IMutableCache declaration. Sorry for the inconvenience. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
