Any issues using multiple GAE app versions to get multiple apps to share the same datastore?

Question

According to the research I've done (see for example this gae issue and this stack overflow question), it is not possible to share one datastore across two applications, and most folks recommend using either the RemoteAPI or using multiple "versions" of the same application, where each version is really an entirely different application. According to GoogleAppEngine Issue 1300, allowing multiple GAE applications to share the same datastore has been "accepted" which presumably means that this feature may be officially supported some day.

I'm hesitant to use the RemoteAPI because I suspect there will be a performance penalty for me in the part of my app where response time is critical. So I'm wondering if anyone has used the approach of using multiple versions under the same application ID to share the same datastore? If so, would you be able to comment on whether you have found any problems with this approach? Presumably this does not violate the GAE license terms that generally prohibit multiple distinct applications from behaving like one application?

David

Update: I gave this approach a try and have some possible issues to report about this approach. When deploying my two applications as two versions of the same app on my local GAE instance (on ports 8080 and 8081), updates I make with one application are not always seen by the other application until I Stop/Start it. I do not see this behavior on appspot.com. I think the broader issue here is that I was assuming that the high replication data store had similar transactional properties as a traditional SQL database. What's happening is that there seems to be a significant delay between when changes are committed by one application, and when they're available to be read by the other application. Wondering if there's a way to effectively "flush" your changes, or clear a cache somewhere in order to get commits made by one app to show up in queries made by the other. Or maybe I'm barking down the wrong rabbit hole...

Answer 1

One reason for not doing it would be that every deployment will come with a temporary outage - between when the instances running the old code are being shut down and instances running the new code are started. Gradual/graceful traffic switchover is not possible (it requires different versions).

Occasionally these outages can be extended, requiring human intervention for recovery, see Continuous integration/deployment/delivery on Google App Engine, too risky?.

Another reason would be trouble mapping such version-based "apps" to custom domains, see How to use custom domain name in google app engine with different versions?

FWIW, these days a much better way to achieve the same result is using different services/modules for such "apps", see Service isolation.

Answer 2

The code which interacts with persistence layer and datastore should be same across all versions is biggest thing you should take care of (Assuming they are doing operation on same set of entities). Since datastore is entity based, and it's upto your application to manage entities, so it's very easy to have a different persistence code and create anamolies in DB. UI and business logic layer should be fine as such.

Answer 3

Using multiple versions for this is a fine way to do this, and there is no problem with the terms of service -- however you may not be able to provide round-the-clock service for multiple apps using only the free quota.

Do note that this means that you have to be extra careful about using the correct version when updating an app, and you can't easily use versions for other purposes simultaneously, since the version is now part of the URL that users use to access an app.

Also, admin console permissions cannot be differentiated between different versions.

Finally, there may be some scheduler features (maybe instance control?) that only apply to the default version; I'm not the right person to answer that.