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.
Jules
James
-------
http://radio.weblogs.com/0112098/
--
"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)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
