Thanks for sharing it, I will see how I can use it. I use Guice though, so I am injecting repositories into classes and then just calling persist. So not sure if that can work be initiated before somehow.
And it looks like I won't be able to test anything today, I just run out of free quota, when trying to clean up over 30k _ah_SESSION entities... On Dec 18, 10:41 am, Ian Marshall <[email protected]> wrote: > Hi Paul, > > Enqueuing a task at start-up to instantiate a PMF instance > ---------------------------------------------------------- > > First, some code. > > private static String g_sDatabaseMode = null; > private static final Object objLockPMF = new Object(); > private static volatile PersistenceManagerFactory g_pmf = null; > > /** > * If this class's static singleton <code>PersistenceManagerFactory</code> > * is <code>null</code>, then construct it in a synchronised block of code. > * @return > * This class's static singleton <code>PersistenceManagerFactory</code>. > */ > public static PersistenceManagerFactory getPersistenceManagerFactory() > { > if (g_pmf == null) > synchronized(objLockPMF) > { > if (g_pmf == null) > { > loadProperties(); // Sets g_sDatabaseMode > g_pmf = JDOHelper.getPersistenceManagerFactory(g_sDatabaseMode); > } > } > > return g_pmf; > } > > On a first hit of my web application's home page, a task is enqueued for > immediate execution. This task calls the above method. In effect, I am using > a separate "thread" to initialise the WebAplication class's singleton > instance of a PersistenceManagerFactory. Since the method > > PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory(String > s); > > takes a few seconds to return, my use of an enqueued task means that this > delay is not shown to the user. Exception: since all my code to exchange data > with the datastore uses the above method, a user's attempt to do something > before the above call has returned (from the home page or otherwise) will > involve a delay to wait for the call to complete, since my typical datastore > data exchange code is like this: > > PersistenceManagerFactory pmf = > DataExchange.getPersistenceManagerFactory(); > PersistenceManager pm = pmf.getPersistenceManager(); > Transaction tx = pm.currentTransaction(); > try > { > tx.begin(); > > // > // Do data exchange stuff > // > > tx.commit(); > } > finally > { > try > { > if (tx.isActive()) // Because of an exception, say > tx.rollback(); > } > finally > { > pm.close(); > } > } > > Any help? > > Ian > > > > > > > > -------- Original Message -------- > Subject: [google-appengine] Re: Problem updating my project to new SDK > Date: Sat, 17 Dec 2011 06:24:14 -0800 (PST) > From: Paul <[email protected]> > > Reply-To: [email protected] > To: Google App Engine <[email protected]> > > I use JDO too, I have built my app on top of that maven archetype with > JDO and Wicket. With Guice too. > > I really like same things you mentioned and I am still constantly > surprised that people prefer JSP and JSF. I have to work on Oracle's > ADF at my day job, really ugly stuff. > > My home page does not exchange data with datastore, at least not > initially [it has login screen]. Could you tell me more about point > 1? > > On Dec 16, 10:36 am, Ian Marshall<[email protected]> wrote: > > I love Wicket. I can use my Java experience (and I really like Java > > too). Wicket is my first web development framework, and I love the > > clean split between the HTML and Java code (for me, the links between > > them are just some wicket tags). I do not do all this servlet and > > related stuff; I let Wicket do all that for me! > > > As for start-up times, what's your data persistence technology? I use > > JDO. For this, there is a many-second period required to instantiate a > > JVM's singleton instance of a persistence manager factory (PMF). My > > ways to cope with this are: > > 1. Enqueue a task at start-up to instantiate a PMF instance. > > 2. Ensure that the home page does not need to exchange data with > > the datastore. > > > My start-up times can be very slow for my zero traffic due to a new > > JVM being started, but that's nothing to do with Wicket or JDO. I can > > always have a JVM instance always on to counter this. > > > -------- Original Message -------- > > > I will take a look at that, it was quite mysterious to me, as I have > > even deleted all old sdks from my disk and changed all reference. > > > Anyway, are you happy with Apache Wicket? I am quite early with my > > project and I really like Wicket. I am a bit worried about performance > > though - do you have any issues with that? How about startup times? > > Mines are really slow, but I am not sure if Wicket has anything to do > > with it. > > > On Dec 14, 9:47 am, Ian Marshall<[email protected]> wrote: > > > I believe that the GAE/J SDK files we have in our > > > > war\WEB-INF\lib > > > > folder dictate to GAE/J which version of the SDK we want to be run in > > > production. For example: I have > > > > appengine-api-1.0-sdk-1.5.5.jar > > > > amongst other .jar files, so my app will run under the Java 1.5.5 SDK > > > when deployed in production. (Yes, I haven't upgraded my build > > > environment to take the newest SDK into account. > > > > Any help? (Hello fellow Apache Wicket developer!) > > > > On Dec 14, 8:59 am, Paul<[email protected]> wrote: > > > > > Hi, > > > > > I am trying to update to the new SDK in my project settings. I am not > > > > using Eclipse plugin as it does not work. I use maven for running and > > > > deploying. Even though my xml points to newest sdk, it does not work > > > > and shows standard message about older sdk version. When running > > > > locally it uses correct version, but not always. But when deploying > > it > > > > shows that I'm using 2-3 versions older SDK. Am I missing something? -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
