Bruce Snyder wrote:
On 10/15/05, Jules Gosnell <[EMAIL PROTECTED]> wrote:
Jeff Genender wrote:
Jules,
Thanks for the update. I like whats been done. Do you think WADI is
ready begin becoming a part of Geronimo? (i.e ready for prime time)
I have lots more to do, but I would certainly be interesting in starting
integration work with Geronimo. I always had Geronimo in mind whilst
working on WADI, it has just been that, until certification, simply
implementing specs correctly has been foremost on the G agenda. Now that
we have reached this goal, the next one becomes enterprise-readiness. I
hope that WADI can help with this. Would you, or anyone else on the
list, be interested in taking a look at it and getting involved in the
integration ?
I'm definitely interested in getting involved with this, Jules. In
fact, I've already typed in the JCache interfaces and only need to
commit them to the Geronimo repo (and then work on converting OpenEJB
2 to use them, of course). This spec will most certainly help out any
mechanism needing caching.
Glad to hear we will have a JCache API done - good work.
I have a few provisos about assuming that JCache is THE solution to this
range of problems and this is the reason why I rejected the JCache API
on my last redesign of WADI (although I think that the next one will
have to incorporate it and extend it).
JCache focusses (as far as my understanding goes), simply on the
location of the state required by a process and not the location of the
process itself. WADI tries to be neutral in this respect and should be
equally at home relocating state to process or process to state. e.g. I
can migrate a session in underneath an incoming request, or
redirect/proxy a request to the node holding the state (and then 'stick'
the client to this node so that subsequent requests travel directly to
the session's location). The latter solution has distinct advantages :
1. Http requests are often much smaller than Http sessions. (the same
would hold true for an EJB invocation and a SFSB)
2. Many Http requests may run through an HttpSession concurrently, but
an HttpSession may only be in one place at once. i.e., if a number of
nodes all receive an http request for the same session it is quicker for
them to all relocate their requests to the session in question, where
they may run concurrently, than to relocate the session from request to
request which may only be done serially. This is not an issue with an
SFSB (I assume) since only one thread is allowed access to an SFSB at
any one time anyway (I think?).
3. [de]serialisation is expensive and error prone (may tickle bugs in
application code). HttpSessions may have activation/passivation
listeners registered (is there an equivalent for SFSBs?) which could be
expensive to call. If we can avoid moving a session, it is a good thing.
4. The optimal location for a session is on the same node as its bucket
owner. If the two can be colocated, notifications about creation,
relocation and destruction can be run locally instead of remotely. So
once this colocation is achieved (which it should be from the start,
since each node can restrict itself to only generating session ids which
map to buckets of which it is the owner), we want to avoid moving the
session again, perhaps even if a request for it lands elsewhere.
So, I guess, whilst you have your head in the JCache API and are looking
at JCache and OpenEJB, these would be very useful facts to consider.
What is going to be the best way to fit these requirements into an
architecture that sits around a JCache ? Perhaps we define an additional
API which allows the relocation of an 'invocation' to a given
CacheEntry, rather than the other way around. If the JCache instance
that we are using implements this interface, then we enable the
request-relocation functionality. Then we will be able to run our stuff
with other jcache impls (which is bound to be a requirement), or our
own, in which case you get the extra fn-ality....
Sound like a good idea ?
Jules
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
--
"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.
**********************************/
