incubator-wadi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: [wadi-dev] Re: Clustering - WADI/ActiveSpace Synergy...
Date Mon, 30 Jan 2006 11:57:31 GMT
James Strachan wrote:

> 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.

Good - we agree then :-)

So, I guess I need to roll back a little on the WADI/AS convergence 
thing and then move forward again in a slightly different direction...

Rather than a 'Meet' reusing a Cache, we should consider sharing 
components/fn-ality at a lower level, where the difference between a 
Mapped item and an Unmapped one is not significant. Being able to use 
WADI's PartitionManager in AS, or AS' transaction support in WADI would 
be two potential benefits here...

> 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)

Sure, understood.

Thanks for the clarification.


> James
> -------

"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * Open Source Training & Support.

View raw message