Re: [appengine-java] Re: JDO second level cache getting in the way...
Thank you, Andy, for this information! I have upgraded to DataNucleus plugin 2.0.0-RC2 which solves the issue in my development environment. Can I use this version (RC2) in the GAE production environment as well? Can I use the same deployment procedure from within Eclipse as with the DataNucleus plugin bundled with the GAE SDK? Thank you, Peter On Thu, Jan 5, 2012 at 5:49 AM, datanucleus andy_jeffer...@yahoo.comwrote: @Rick, JDO doesn't encourage you to do anything, nor impose it. Perhaps its just that some will, upon using it, think in a particular way because they used a similar API before, and they're used to their good old RDBMS handling things for them so assume the same is true ... and it isn't as you say. Doesn't mean they can't bundle things together with JDO to minimise query impact also. @Peter, You observe behaviour in a very old version of software, and nontransactional operations in that version did things differently (though still comparable to the likes of Hibernate). The v2 version of Googles plugin makes use of recent software and all nontransactional persists/deletes are atomic. Obviously you could just put things in a transaction and you'd be fine too. Read about caches here http://www.datanucleus.org/products/accessplatform_3_0/jdo/cache.html -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: JDO second level cache getting in the way...
Perhaps I am thinking of JDO and JPA as being more similar than I should, but I've found that GAE doesn't really want you to think of your datastore in an OO manner either. It's a collection of documents and indexes. JDO (and JPA) encourage you to model your objects as you would in any sane system and then let you forget about the mapping to the underlying datastore as much as possible. That's awesome for most environments. But IMHO (and admittedly with only a few months of time trying to wrap my head around a JDO application I inherited, yes with the old plugin) this is not the best way to work with the GAE Datastore. I'm sure it works fine for many projects, but traversing large trees of objects one at a time is very costly in terms of performance. I've found that it's much more efficient to store the data you need from related objects in the parent directly or in another record using partial decomposition. That also makes using the memcache service to cache larger result sets much easier, and you don't wind up needing a lot of indexes to perform complex queries since you can search on records that have been created ahead of time. Yes, you can do this with JDO, but in my opinion JDO creates a layer of abstraction that you don't need and one that gets in the way. On Jan 3, 2:52 am, datanucleus andy_jeffer...@yahoo.com wrote: JDO was designed for relational data models, GAE was designed for the opposite. Please check your facts, perhaps by consulting people who actually designed the JDO standard, or by actually reading the JDO spec. It was designed to be datastore-agnostic. JPA on the other hand was not, with RDBMS syntax leaking through the query language. Use of version 2 of the GAE plugin (included as optional in 1.6.1 SDK) is recommended, fixing many shortcomings in the design of the original plugin -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: JDO second level cache getting in the way...
Many thanks, Rick, for bringing to my attention these apparently useful
alternatives! I hopefully will find time to try them.
Thanks,
Peter
On Mon, Jan 2, 2012 at 9:00 PM, Rick Mangi r...@broadcastr.com wrote:
Do yourself a big favor and run away from JDO + GAE screaming as fast
as you can. You're much better off using one of the thin wrappers
around the AppEngine Datastore like Objectify or Twig along with the
built in Memcache service.
JDO was designed for relational data models, GAE was designed for the
opposite. They don't play well together. You *can* get them to work,
and many have, but I have yet to find anyone who enjoyed the
experience.
best,
Rick
On Jan 1, 7:07 pm, The night manager peter.dunay.kov...@gmail.com
wrote:
Hi,
I am new to both GAE and JDO. I would be grateful if someone could
provide
guidance on a behavior I find rather counter-intuitive. In the following
code, I have to call pm.evictAll() to successfully/persistently change
properties (labels) on a freshly persisted object (bookmark):
PersistenceManager pm = PMF.get().getPersistenceManager();
try {
Bookmark bookmark = new Bookmark(url);
bookmark = pm.makePersistent(bookmark);
pm.evictAll();
Key k = bookmark.getKey();
bookmark = pm.getObjectById(Bookmark.class, k);
bookmark.addLabels(labels);
} finally {
pm.close();
}
I'd naively expect the above code to persistently adding labels to
bookmarkseven without calling
pm.evictAll()and with explicitly (re-)fetching the bookmark object. I'd
expect JDO to notice that the Bookmark instance has been dirtied and
pm.close() to persist the changes to the cached object.
I find it also counter-intuitive that pm.evict(bookmark) doesn't work --
the entire cache needs to be cleared for new labels on bookmark to get
persisted. (Even though pm.evict(Object) appears to expect a *
persistent-clean* object, which, in turn, appears to assume being in a
transaction...)
Any pointers on the reasons of this behavior will be gratefully
appreciated.
Peter
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to
google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: JDO second level cache getting in the way...
Many thanks, Andy, for the clarification. I am still not sure which of the following statements describes the best the behaviour I observe: it is (a) the intended behaviour, (b) not intended, just happens to be like this or (c) a bug. After regarding cache level: reading fleetingly through the JDO specification (3.0), nothing sticks out to indicate that the JDO implementation is supposed to manage any other cache than the second level cache. (void evictAll() itself is listed under the *11.8 Second-level cache management* section.) I am not sure what Level 1 cache may be...is it, perhaps, an artifact of the datanucleus implementation? Thanks Peter On Wed, Jan 4, 2012 at 6:04 AM, datanucleus andy_jeffer...@yahoo.comwrote: As for the problem of the original poster, evictAll is for the *Level1* cache (which will not be of any use since you aren't using transactions there). Calling addLabels is queued (doesn't go straight to the DB in the version you use there), and you don't then start a transaction. Simple thing to do to get around it would be pm.currentTransaction().begin(); pm.currentTransaction().commit(); after the addLabels. You can help yourself by looking at the log, since it explains way more than that (at DEBUG level). -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: JDO second level cache getting in the way...
@Rick, JDO doesn't encourage you to do anything, nor impose it. Perhaps its just that some will, upon using it, think in a particular way because they used a similar API before, and they're used to their good old RDBMS handling things for them so assume the same is true ... and it isn't as you say. Doesn't mean they can't bundle things together with JDO to minimise query impact also. @Peter, You observe behaviour in a very old version of software, and nontransactional operations in that version did things differently (though still comparable to the likes of Hibernate). The v2 version of Googles plugin makes use of recent software and all nontransactional persists/deletes are atomic. Obviously you could just put things in a transaction and you'd be fine too. Read about caches here http://www.datanucleus.org/products/accessplatform_3_0/jdo/cache.html -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: JDO second level cache getting in the way...
JDO was designed for relational data models, GAE was designed for the opposite. Please check your facts, perhaps by consulting people who actually designed the JDO standard, or by actually reading the JDO spec. It was designed to be datastore-agnostic. JPA on the other hand was not, with RDBMS syntax leaking through the query language. Use of version 2 of the GAE plugin (included as optional in 1.6.1 SDK) is recommended, fixing many shortcomings in the design of the original plugin -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: JDO second level cache getting in the way...
As for the problem of the original poster, evictAll is for the *Level1* cache (which will not be of any use since you aren't using transactions there). Calling addLabels is queued (doesn't go straight to the DB in the version you use there), and you don't then start a transaction. Simple thing to do to get around it would be pm.currentTransaction().begin(); pm.currentTransaction().commit(); after the addLabels. You can help yourself by looking at the log, since it explains way more than that (at DEBUG level). -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: JDO second level cache getting in the way...
Do yourself a big favor and run away from JDO + GAE screaming as fast
as you can. You're much better off using one of the thin wrappers
around the AppEngine Datastore like Objectify or Twig along with the
built in Memcache service.
JDO was designed for relational data models, GAE was designed for the
opposite. They don't play well together. You *can* get them to work,
and many have, but I have yet to find anyone who enjoyed the
experience.
best,
Rick
On Jan 1, 7:07 pm, The night manager peter.dunay.kov...@gmail.com
wrote:
Hi,
I am new to both GAE and JDO. I would be grateful if someone could provide
guidance on a behavior I find rather counter-intuitive. In the following
code, I have to call pm.evictAll() to successfully/persistently change
properties (labels) on a freshly persisted object (bookmark):
PersistenceManager pm = PMF.get().getPersistenceManager();
try {
Bookmark bookmark = new Bookmark(url);
bookmark = pm.makePersistent(bookmark);
pm.evictAll();
Key k = bookmark.getKey();
bookmark = pm.getObjectById(Bookmark.class, k);
bookmark.addLabels(labels);
} finally {
pm.close();
}
I'd naively expect the above code to persistently adding labels to
bookmarkseven without calling
pm.evictAll()and with explicitly (re-)fetching the bookmark object. I'd
expect JDO to notice that the Bookmark instance has been dirtied and
pm.close() to persist the changes to the cached object.
I find it also counter-intuitive that pm.evict(bookmark) doesn't work --
the entire cache needs to be cleared for new labels on bookmark to get
persisted. (Even though pm.evict(Object) appears to expect a *
persistent-clean* object, which, in turn, appears to assume being in a
transaction...)
Any pointers on the reasons of this behavior will be gratefully appreciated.
Peter
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
