incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [wadi-dev] Re: Clustering - WADI/ActiveSpace Synergy...
Date Mon, 30 Jan 2006 11:40:20 GMT
On 30 Jan 2006, at 11:00, Jules Gosnell wrote:
> James Strachan wrote:
>> On 30 Jan 2006, at 10:29, Jules Gosnell wrote:
>>> James Strachan wrote:
>>>> On 30 Jan 2006, at 10:06, Jules Gosnell wrote:
>>>>> Finally, as discussed with James on numerous occasions, we   
>>>>> should  look at how WADI's pessimistic locking and   
>>>>> PartitionManager might  be componentised so that they can be   
>>>>> plugged into AS to provide  Cache and Space users, who are not   
>>>>> interested in location- independance, with a pessimistic  
>>>>> approach  and/or a partitioned  clustering substrate...
>>>> BTW I don't see using a pessimistic lock as being very useful  
>>>> for  a  cache; typically in a JCache scenario you are caching  
>>>> state  that is  stored in some database/system; so if you really  
>>>> want a  pessimistic  lock you should lock the database (they are  
>>>> very good  at doing  distributed locks) rather than having a  
>>>> pessimistic lock  in a cache  which is a different lock to where  
>>>> the actual data is.
>>> Agreed - but in the case of a distributed session, it may not be   
>>> mapped to a database.... - I guess we are not a typical JCache   
>>> scenario ?
>> Exactly. JCache is usually used for distributed caching of  
>> persistent  state. So for most users of JCache, pessimistic  
>> locking has no real  value.
>> The exception to this rule is for folks who want to use JCache as  
>> a  database (being the master copy of the state) which is usually  
>> as a  result of folks trying to solve the distributed-session- 
>> state  problem. But its much better IMHO to just solve the  
>> distributed  session state problem correctly than turn JCache into  
>> a database :)
> not sure that I follow you here - so you are saying 'don't use  
> jcache for distributed sessions' ? - or am I misunderstanding ? How  
> would you 'solve the distributed  session state problem correctly' ?

I'm saying that reusing JCache as a database to solve the distributed  
session state problem is more a case of trying to find a problem to  
reuse a solution rather than actually trying to find the best  
solution to the problem (quite a common occurrence in IT). If you  
have a hammer all problems look like nails to be bashed.

Sure you could use JCache for the distributed session problem, just  
as you could use a database - but its not necessarily the best  
solution, depending on your requirements; there are leaky  
abstractions in there. As usual in IT, it depends on exactly which  
distributed-state-problem you are trying to solve and what your  
requirements are.

e.g. I'd hope WADI was a better solution to the distributed session  
problem than just using JCache as WADI is designed as a solution to  
the problem; JCache is designed for the distributed caching of  
(usually persistent or expensive-to-generate) state.

Though rather like messaging; there's a zillion ways of solving the  
problem; which is why I'm a big fan of nice simple, abstract APIs to  
specific technology problems so that implementation diversity can be  
hidden behind the API. (e.g. the JMS API for messaging, the Session  
API for distributed state management and JCache for distributed caching)


View raw message