Read-only and in-memory and databases such as the H2 Database Engine
and HSQLDB should work. Also supported should be tools that use a
subset of the JDBC API, such as the tool to read a CSV file as a
ResultSet (included in the H2 Database Engine).
It's true, there's nothing preventing an in-memory database from working,
but keep in mind that with App Engine you can't make good assumptions about
the state of the server you're hitting across requests. So, while one
request might initialize HSQLDB and load some data into memory, there's no
guarantee a subsequent request is going to hit the server that has already
performed this work. If you're looking to manage state across requests but
don't want to use the datastore, I'd recommend using the memcache service
instead.
As for reading a CSV file as a ResultSet, that should be fine provided you
upload the CSV file as part of your application and that you don't need to
write to that file. I suspect that's not too useful though...
Max
On Wed, Apr 8, 2009 at 4:38 AM, Thomas Mueller <thomas.tom.muel...@gmail.com
> Read-only and in-memory and databases such as the H2 Database Engine
> and HSQLDB should work. Also supported should be tools that use a
> subset of the JDBC API, such as the tool to read a CSV file as a
> ResultSet (included in the H2 Database Engine).
I am the author of the H2 Database Engine, and I think about writing an open source "JDBC to com.google.appengine.api.datastore wrapper". That way people can use SQL and the JDBC API (or other libraries that use it).
Sounds very interesting! It would certainly open up a lot of additional
frameworks for use on App Engine. I can't think of any security
restrictions that would prevent you from implementing a jdbc driver that
wraps the datastore service, so by all means go for it!
Max
On Wed, Apr 8, 2009 at 1:55 PM, Thomas Mueller <thomas.tom.muel...@gmail.com
> I am the author of the H2 Database Engine, and I think about writing
> an open source "JDBC to com.google.appengine.api.datastore wrapper".
> That way people can use SQL and the JDBC API (or other libraries that
> use it).
does that mean my web app could in theory be running in multiple jvms
simultanously? and is that also the reason google provides an
implementation of servlet session using datastore?
On Apr 9, 1:55 am, Max Ross <maxr+appeng...@google.com> wrote:
> It's true, there's nothing preventing an in-memory database from working,
> but keep in mind that with App Engine you can't make good assumptions about
> the state of the server you're hitting across requests. So, while one
> request might initialize HSQLDB and load some data into memory, there's no
> guarantee a subsequent request is going to hit the server that has already
> performed this work. If you're looking to manage state across requests but
> don't want to use the datastore, I'd recommend using the memcache service
> instead.
> As for reading a CSV file as a ResultSet, that should be fine provided you
> upload the CSV file as part of your application and that you don't need to
> write to that file. I suspect that's not too useful though...
> Max
> On Wed, Apr 8, 2009 at 4:38 AM, Thomas Mueller <thomas.tom.muel...@gmail.com
> > wrote:
> > Read-only and in-memory and databases such as the H2 Database Engine
> > and HSQLDB should work. Also supported should be tools that use a
> > subset of the JDBC API, such as the tool to read a CSV file as a
> > ResultSet (included in the H2 Database Engine).
Yes and yes, although the datastore-backed session is important not just
because your app may be running in multiple jvms but because we don't make
any guarantees about the lifespan of any particular jvm. In short, you can
try to optimize for the case where requests are being served by the same jvm
but you should never depend on it.
On Sat, Apr 11, 2009 at 1:24 AM, walterc <weih...@gmail.com> wrote:
> does that mean my web app could in theory be running in multiple jvms
> simultanously? and is that also the reason google provides an
> implementation of servlet session using datastore?
> On Apr 9, 1:55 am, Max Ross <maxr+appeng...@google.com<maxr%2Bappeng...@google.com>>
> wrote:
> > It's true, there's nothing preventing an in-memory database from working,
> > but keep in mind that with App Engine you can't make good assumptions
> about
> > the state of the server you're hitting across requests. So, while one
> > request might initialize HSQLDB and load some data into memory, there's
> no
> > guarantee a subsequent request is going to hit the server that has
> already
> > performed this work. If you're looking to manage state across requests
> but
> > don't want to use the datastore, I'd recommend using the memcache service
> > instead.
> > As for reading a CSV file as a ResultSet, that should be fine provided
> you
> > upload the CSV file as part of your application and that you don't need
> to
> > write to that file. I suspect that's not too useful though...
> > Max
> > On Wed, Apr 8, 2009 at 4:38 AM, Thomas Mueller <
> thomas.tom.muel...@gmail.com
> > > wrote:
> > > Read-only and in-memory and databases such as the H2 Database Engine
> > > and HSQLDB should work. Also supported should be tools that use a
> > > subset of the JDBC API, such as the tool to read a CSV file as a
> > > ResultSet (included in the H2 Database Engine).
How likely is it that your requests will be served from the same JVM? Is it worth even optimizing on that case, or are you better off
optimizing on flat scaling across the cloud?
> Yes and yes, although the datastore-backed session is important not
> just
> because your app may be running in multiple jvms but because we
> don't make
> any guarantees about the lifespan of any particular jvm. In short,
> you can
> try to optimize for the case where requests are being served by the
> same jvm
> but you should never depend on it.
> Max
> On Sat, Apr 11, 2009 at 1:24 AM, walterc <weih...@gmail.com> wrote:
>> does that mean my web app could in theory be running in multiple jvms
>> simultanously? and is that also the reason google provides an
>> implementation of servlet session using datastore?
>> On Apr 9, 1:55 am, Max Ross <maxr+appeng...@google.com<maxr >> %2Bappeng...@google.com>>
>> wrote:
>>> It's true, there's nothing preventing an in-memory database from
>>> working,
>>> but keep in mind that with App Engine you can't make good
>>> assumptions
>> about
>>> the state of the server you're hitting across requests. So, while
>>> one
>>> request might initialize HSQLDB and load some data into memory,
>>> there's
>> no
>>> guarantee a subsequent request is going to hit the server that has
>> already
>>> performed this work. If you're looking to manage state across
>>> requests
>> but
>>> don't want to use the datastore, I'd recommend using the memcache
>>> service
>>> instead.
>>> As for reading a CSV file as a ResultSet, that should be fine
>>> provided
>> you
>>> upload the CSV file as part of your application and that you don't
>>> need
>> to
>>> write to that file. I suspect that's not too useful though...
>>> Max
>>> On Wed, Apr 8, 2009 at 4:38 AM, Thomas Mueller <
>> thomas.tom.muel...@gmail.com
>>>> wrote:
>>>> Read-only and in-memory and databases such as the H2 Database
>>>> Engine
>>>> and HSQLDB should work. Also supported should be tools that use a
>>>> subset of the JDBC API, such as the tool to read a CSV file as a
>>>> ResultSet (included in the H2 Database Engine).
It's certainly worth optimizing, but be cautious about how you do it. For
example, if you have static or slow-changing data that is needed by a large
percentage of your requests, caching that data to avoid the datastore hit is
worthwhile. The question is, do you read that data into a static cache tied
to a single jvm instance or do you read it into memcache, which is shared
across all the jvms from which your app is serving? I'd start with memcache
and see if that gets you the performance you need. Looking at our system
status dashboard, you can see that a memcache get for 10kb of data takes
between 6 and 24 milliseconds:
Pretty darn speedy. Pushing data in has similar performance
characteristics. So if you cache in memcache you get super fast lookups
that are independent of the jvm your app happens to be serving from. You
_could_ cache using memory that is specific to your jvm, and it will be
faster, but you may find yourself reloading that data more often because the
data will go away with the jvm.
Max
On Sat, Apr 11, 2009 at 11:46 AM, Christian Edward Gruber <
> How likely is it that your requests will be served from the same JVM?
> Is it worth even optimizing on that case, or are you better off
> optimizing on flat scaling across the cloud?
> Christian.
> On 11-Apr-09, at 13:18 , Max Ross wrote:
> > Yes and yes, although the datastore-backed session is important not
> > just
> > because your app may be running in multiple jvms but because we
> > don't make
> > any guarantees about the lifespan of any particular jvm. In short,
> > you can
> > try to optimize for the case where requests are being served by the
> > same jvm
> > but you should never depend on it.
> > Max
> > On Sat, Apr 11, 2009 at 1:24 AM, walterc <weih...@gmail.com> wrote:
> >> does that mean my web app could in theory be running in multiple jvms
> >> simultanously? and is that also the reason google provides an
> >> implementation of servlet session using datastore?
> >> On Apr 9, 1:55 am, Max Ross <maxr+appeng...@google.com<maxr%2Bappeng...@google.com>
> <maxr
> >> %2Bappeng...@google.com>>
> >> wrote:
> >>> It's true, there's nothing preventing an in-memory database from
> >>> working,
> >>> but keep in mind that with App Engine you can't make good
> >>> assumptions
> >> about
> >>> the state of the server you're hitting across requests. So, while
> >>> one
> >>> request might initialize HSQLDB and load some data into memory,
> >>> there's
> >> no
> >>> guarantee a subsequent request is going to hit the server that has
> >> already
> >>> performed this work. If you're looking to manage state across
> >>> requests
> >> but
> >>> don't want to use the datastore, I'd recommend using the memcache
> >>> service
> >>> instead.
> >>> As for reading a CSV file as a ResultSet, that should be fine
> >>> provided
> >> you
> >>> upload the CSV file as part of your application and that you don't
> >>> need
> >> to
> >>> write to that file. I suspect that's not too useful though...
> >>> Max
> >>> On Wed, Apr 8, 2009 at 4:38 AM, Thomas Mueller <
> >> thomas.tom.muel...@gmail.com
> >>>> wrote:
> >>>> Read-only and in-memory and databases such as the H2 Database
> >>>> Engine
> >>>> and HSQLDB should work. Also supported should be tools that use a
> >>>> subset of the JDBC API, such as the tool to read a CSV file as a
> >>>> ResultSet (included in the H2 Database Engine).
Hmm. I'm wondering, then, if the @Persist annotation on Tapestry5
could be back-ended by Memcache, rather than the local session - or is
the session distributed through memcache?
> It's certainly worth optimizing, but be cautious about how you do
> it. For
> example, if you have static or slow-changing data that is needed by
> a large
> percentage of your requests, caching that data to avoid the
> datastore hit is
> worthwhile. The question is, do you read that data into a static
> cache tied
> to a single jvm instance or do you read it into memcache, which is
> shared
> across all the jvms from which your app is serving? I'd start with
> memcache
> and see if that gets you the performance you need. Looking at our
> system
> status dashboard, you can see that a memcache get for 10kb of data
> takes
> between 6 and 24 milliseconds:
> Pretty darn speedy. Pushing data in has similar performance
> characteristics. So if you cache in memcache you get super fast
> lookups
> that are independent of the jvm your app happens to be serving
> from. You
> _could_ cache using memory that is specific to your jvm, and it will
> be
> faster, but you may find yourself reloading that data more often
> because the
> data will go away with the jvm.
> Max
> On Sat, Apr 11, 2009 at 11:46 AM, Christian Edward Gruber <
> christianedwardgru...@gmail.com> wrote:
>> How likely is it that your requests will be served from the same JVM?
>> Is it worth even optimizing on that case, or are you better off
>> optimizing on flat scaling across the cloud?
>> Christian.
>> On 11-Apr-09, at 13:18 , Max Ross wrote:
>>> Yes and yes, although the datastore-backed session is important not
>>> just
>>> because your app may be running in multiple jvms but because we
>>> don't make
>>> any guarantees about the lifespan of any particular jvm. In short,
>>> you can
>>> try to optimize for the case where requests are being served by the
>>> same jvm
>>> but you should never depend on it.
>>> Max
>>> On Sat, Apr 11, 2009 at 1:24 AM, walterc <weih...@gmail.com> wrote:
>>>> does that mean my web app could in theory be running in multiple
>>>> jvms
>>>> simultanously? and is that also the reason google provides an
>>>> implementation of servlet session using datastore?
>>>> On Apr 9, 1:55 am, Max Ross <maxr+appeng...@google.com<maxr >>>> %2Bappeng...@google.com>
>> <maxr
>>>> %2Bappeng...@google.com>>
>>>> wrote:
>>>>> It's true, there's nothing preventing an in-memory database from
>>>>> working,
>>>>> but keep in mind that with App Engine you can't make good
>>>>> assumptions
>>>> about
>>>>> the state of the server you're hitting across requests. So, while
>>>>> one
>>>>> request might initialize HSQLDB and load some data into memory,
>>>>> there's
>>>> no
>>>>> guarantee a subsequent request is going to hit the server that has
>>>> already
>>>>> performed this work. If you're looking to manage state across
>>>>> requests
>>>> but
>>>>> don't want to use the datastore, I'd recommend using the memcache
>>>>> service
>>>>> instead.
>>>>> As for reading a CSV file as a ResultSet, that should be fine
>>>>> provided
>>>> you
>>>>> upload the CSV file as part of your application and that you don't
>>>>> need
>>>> to
>>>>> write to that file. I suspect that's not too useful though...
>>>>> Max
>>>>> On Wed, Apr 8, 2009 at 4:38 AM, Thomas Mueller <
>>>> thomas.tom.muel...@gmail.com
>>>>>> wrote:
>>>>>> Read-only and in-memory and databases such as the H2 Database
>>>>>> Engine
>>>>>> and HSQLDB should work. Also supported should be tools that use a
>>>>>> subset of the JDBC API, such as the tool to read a CSV file as a
>>>>>> ResultSet (included in the H2 Database Engine).
I'm looking forward to your JDBC wrapper!
Now, we're able to try to migrate our products and services written in
Java to GAE but those don't use JDO/JPA.
And I think that your work is very important for GAE because it allows
people can migrate a lot of existing their J2EE based web application
to GAE around the world.
|
