28 Jul
2009
28 Jul
'09
8:48 a.m.
(On Wed, Jul 22, 2009 at 12:07 PM, Ludovic Dubost <ludovic(a)xwiki.org> wrote:
I have a prototype of XWIki partially working with some changes on app
engine http://xwiki1.appspot.com/bin/view/Main/
I've made all the servlet / jvm part work as well as the cache subsystem.
The main missing piece is a real storage with support for querying.
Ludovic -- thanks for the reply. That looks quite promising. I guess the
"real storage" issue is caused by this:(
http://groups.google.com/group/google-appengine-java/web/will-it-play-in-ap…
)
limitation:
<http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1>
You cannot currently use Hibernate directly. The differences between the
App Engine datastore and SQL were too great to get the standard Hibernate up
and running under App Engine. App Engine does support JDO and JPA, so you
may be able to convert your Hibernate code to use one of these ORM
interfaces.
Will Xwiki support JDO/JPA in the future? Seems like it would be part of the
XWQL<http://dev.xwiki.org/xwiki/bin/view/Design/XWiki+Query+Language+Spe…effort,
correct?
http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-query/jpql-par…
Mentions
"JPA2[2] specification" but it's not clear that other layers wouldn't
use
other API's.
GAE is also looking less exciting now that I look into it more. In a different
thread<http://n2.nabble.com/adding-a-new-jsr-223-scripting-language-to-x…
wrote:
* It could be very useful to employ massive parallelism
via such Clojure*
* scripts, which could achieve a xwiki-based web portal performance akin to
*
* Yahoo's, Google's, etc. For example, the
following describes how Yahoo
works*
* -- and would be quite easy to implement this kind of
processing "for
free"*
* in Clojure with very little code:
http://research.yahoo.com/files/pnuts.pdf ...*
*
*
Wondering whether Google App Engine would be able to host such a massively
parallel application, I check
http://elhumidor.blogspot.com/2009/04/clojure-on-google-appengine.html which
says:
THE BIG CAVEAT
Two unusual aspects of the Google AppEngine environment create pretty major
constraints on your ability to write idiomatic
Clojure.
First, an AppEngine application runs in a security context that doesn't
permit spawning threads, so you won't be able to
use Agents, the
clojure.parallel library, or Futures.
Second, one of the most exciting features of AppEngine is that your
application will be deployed on Google's huge
infrastructure, dynamically
changing its footprint depending on demand. That means you'll potentially be
running on many JVMs at once. Unfortunately this is a strange fit for
Clojure's concurrency features, which are most useful when you have precise
control over what lives on what JVM (and simplest when everything runs on
one JVM). Since shared references (Vars, Refs, and Atoms) are shared only
within a single JVM, they are not suitable for many of their typical uses
when running on AppEngine. You should still use Clojure's atomic references
(and their associated means of modification) for any state that it makes
sense to keep global per-JVM, since there may be multiple threads serving
requests in one JVM. But remember JVMs will come and go during the lifetime
of your application, so anything truly global should go in the Datastore or
Memcache.
The first point means closure isn't that interesting on GAE. Because GAE is
"single threaded" -- how pointless.
Regarding the second point: why would one be using shared references in code
that one wanted purely functional for the purpose of making it decompose
into parallel code without needing to worry about any of the issues raised?
How could one be doing functional programming if side-effects are happening
to the shared references? And how could one expect that code to decompose
into parallel code w/o explicitly handling locking on shared references that
are being changed?
As followup to GAE limitations, see
http://groups.google.com/group/google-appengine-java/web/will-it-play-in-ap…
which
points to
https://sites.google.com/a/wildstartech.com/adventures-in-java/Java-Platfor…
<!-- Disable use of threading for single-threaded
environments such as
the Google AppEngine. -->
...
If the com.sun.faces.enableThreading context parameter is not set to false (or
omitted completely from the web.xml configuration
file) an application
deployed on the Google AppEngine will display a number of different
errors<https://sites.google.com/a/wildstartech.com/adventures-in-java/Ja…
all
caused by the JSF reference implementation's attempts to construct threads.
Niels
http://nielsmayer.com