|
|
|
|
| Index | Recent Threads | Unanswered Threads | Who's Online | Help |
DataNucleus Forum
DataNucleus Support
Documentation
Thread: Effect of datanucleus.cache.collections=false
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 15
|
|
| Author |
|
chrisco
Expert Australia Joined: Nov 24, 2005 Post Count: 706 Status: Offline |
Hi Chris, let us know the results of your experiments. It would be nice if you could write some sort of best practice, lesson learned, or whatever in wiki if Andy agrees. BTW, can you share what AJAX toolkit are you using ? I have used zk in a project, managing lifecycle in ExecutionInit and ExecutionCleanup (PM-per-request) and it has been a nice experience. Guido Yes I should do that to help others. I'm using Echo3 from nextapp and Wicket. In some apps I even manage to combine the two. Using Echo3 is just like writing a Swing application - except it executes in a browser - very nice and it handles all the browser incompatibilities so that saves about 20% off your development time alone! When new browsers like Chrome arrived the Echo3 developers added support for it and then a download of the latest jars was all that was required for my apps to run the same in Chrome as in the preexisting browsers. I love Echo because it allows Java dudes like myself to do everything in server side Java. I can mess with JavaScript like any JS hacker but I don't find it anywhere near as pure, predictable or reliable across browsers like server side Java and Echo3 is. Wicket is good also - very nice component based architecture - with support for inheritance at the markup level. Currently only one section of a base class markup can be overridden in a derived markup which I find limiting. It's a bit like Java only allowing you to have one virtual method per class. The wicket component lifecycle doesn't separate the object contruction phase from the init phase and so you end can up with the usual woes associated with a single phase construction+initialization lifecycle. eg., constructors can't call methods that assume a completely constructed object. ---------------------------------------- Chris Colman http://visualclassworks.com Javelin: Visual modeling & coding with automatic JDO 2/DataNucleus meta data generation. http://expojo.com expojo: Simple dependency injection and exposed POJO domain model pattern |
||
|
|
chrisco
Expert Australia Joined: Nov 24, 2005 Post Count: 706 Status: Offline |
Sorry for the late response: The UI framework I am using is Echo. It's very similar to writing a Swing app only it's deployed on the web. It completely object oriented/component based so you can make reusable components to cut down code size dramatically. ---------------------------------------- Chris Colman http://visualclassworks.com Javelin: Visual modeling & coding with automatic JDO 2/DataNucleus meta data generation. http://expojo.com expojo: Simple dependency injection and exposed POJO domain model pattern |
||
|
|
agrawalr
Novice UK Joined: Feb 16, 2010 Post Count: 43 Status: Offline |
Hi Chrisco What kind of settings would you suggest for production. In this forum you have already suggested two , retainValues=false cache.collections = false Are there any more. Took over 2 months to migrate the app from Kodo to Datanucleus and now the app is not performing. Using classbased ehcache. Appreciate all help. Regards Raj |
||
|
|
chrisco
Expert Australia Joined: Nov 24, 2005 Post Count: 706 Status: Offline |
Here's the key datanucleus.properties settings we use for quite a large enterprise application: # Lifecylce control javax.jdo.option.RetainValues=false javax.jdo.option.RestoreValues=true javax.jdo.option.NontransactionalRead=true # causes any dirty objects to be flushed prior to a query being processed # so that the query deals with an up to date database datanucleus.query.flushBeforeExecution=true # Caching options datanucleus.cache.level1.type=soft # Use DataNucleus' internal L2 cache - fine if you don't need # a distributed cache datanucleus.cache.level2.type=soft # Commented out so that collections *are* cached. # Our domain model has *a lot* of # collections so not caching them means lots more DB access #datanucleus.cache.collections=false # Multithreading - turned off for improved performance but # make sure you have a separate PM per thread datanucleus.Multithreaded=false datanucleus.connectionPoolingType=DBCP datanucleus.identifier.case=lowercase # Need this for backwards compatibility with algorithm for name # generation used by DataNucleus 1 datanucleus.identifierFactory=datanucleus ---------------------------------------- Chris Colman http://visualclassworks.com Javelin: Visual modeling & coding with automatic JDO 2/DataNucleus meta data generation. http://expojo.com expojo: Simple dependency injection and exposed POJO domain model pattern |
||
|
|
agrawalr
Novice UK Joined: Feb 16, 2010 Post Count: 43 Status: Offline |
Hi Chrisco Thanks for sharing the properties. Was there any reason not to use ehcache, I mean was the performance better with default DN cache compared to ehcache ? Query caching is one more thing missing from your setting - again was there any tuning which helped you to drop these settings ? datanucleus.Multithreaded - I don't set this, assuming this is always set to false by default. Need to test, correct me if I am wrong. This could be huge blow to performance if I am to wrong. Rest are same as what I use. Thanks Again Raj |
||
|
|
|
|
Current timezone is GMT May 17, 2012 12:18:33 PM |
