On 30 Nov 2009, at 18:05, Vladimir Blagojevic wrote:
Hi all,
Manik asked me to investigate what it would take to deploy Infinispan
inside google app engine (GAE). As you might have heard GAE execution
environment is somewhat constricted (can not create threads, write to
files, open sockets, etc). Right from a get go it was clear that we can
not run Infinispan in any mode other than local. However, even if
Infinispan is run in local mode GAE users could benefit from
Infinispan's JSR-107 cache interface that is backed up with cache store
implemented using google datastore api. There probably are use case
scenarios where GAE users interact with both google provided JSR-107
memcache service [1] and datastore [2] separately where in fact
Infinispan's JSR-107 interface that is automatically synced with
datastore would make much more sense.
Yup. It would be good to put together a wiki page on how and why this is a good thing,
maybe even with some benchmarks using GAE/J APIs directly and via Infinispan.
Manik and I went back and forth and decided to put this sub project
on a
back burner at this moment. Even though we could accommodate GAE's
thread restriction it turns out that GAE sandbox restrictions involve
several apis that we use (JAXB, JMX, JNDI among others) and retrofitting
Infinispan into this tight sandbox would be a headache. There is a
strong comunity push to unrestrict these API and it seems pressures from
community would eventually be successful.
JAXB is the real headache since our configuration relies on it. The rest - JNDI, JMX -
can all be switched off. TBH, even JAXB is not *critical* as we could support just
programmatic config, but that still is pretty intrusive so I think JAXB is the real
blocker.
Also, I am still awaiting for some feedback from Mircea to see if we
can
even implement google datastore cache loader to be transactional. Even
though GAE datastore supports transactions they are only available in
the same entity group [3]. As far as I understand GAE datastore they
implement horizontal partitioning which basically involves putting
different rows into different tables. Think each Person row entry would
have to be in different table unless they are in some owns (say
parent-child) relationship.
I don't think we need to worry about transactions and cache stores. Propagating
transaction context to a cache store is entirely optional and only if the underlying store
is JTA compliant (e.g., JDBC). Most of our cache stores are not JTA compliant (file
system, S3, etc) but we still work around this quite well - have a look at the
FileCacheStore as an example.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org