|
|
|
|
| Index | Recent Threads | Unanswered Threads | Who's Online | Help |
DataNucleus Forum
DataNucleus Support
Documentation
Thread: Second class objects: containers and PM.refresh
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 4
|
|
| Author |
|
chrisco
Expert Australia Joined: Nov 24, 2005 Post Count: 706 Status: Offline |
Just reading the DataNucleus documentation on second class objects: containers and need some clarification in regard to caching and refreshing of cached objects in a optimistic 'locking' scenario: ... This means that once the values are loaded in that field there will be no need to make any call to the datastore unless changing the container. This gives significant speed ups when compared to relaying all calls via the datastore. It says there will be 'no need to call to the database unless changing the container' but what about when the container is updated (objects added or deleted) by another user/session/PM? Obviously the container is a SCO and so can't be the parameter in a pm.refresh(Object o) method call. Will calling pm.refresh(Object o) on the FCO that owns the SCO container cause the contents of the SCO collection to be flushed and then restored with the values in the peer container in the peer object in the L2 cache (or direct from the DB if not currently in the L2) or does pm.refresh(Object o) only refresh the 'standard' attributes of the object and not it's SCO containers? ---------------------------------------- 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 |
||
|
|
andy
Expert UK Joined: Mar 13, 2004 Post Count: 5686 Status: Offline |
Read the JDO spec. Refresh unloads all fields in the current fetch plan. So if you put your collection in the fetch plan during that operation then they get refreshed. ---------------------------------------- -Andy   |
||
|
|
chrisco
Expert Australia Joined: Nov 24, 2005 Post Count: 706 Status: Offline |
Read the JDO spec. Refresh unloads all fields in the current fetch plan. So if you put your collection in the fetch plan during that operation then they get refreshed. Arh, subtle! JDO 2.2 Spec 12.6.1 When called with a transaction active, the refreshAll method with no parameters causes all transactional instances to be refreshed. If a transaction is not in progress, then this call has no effect. If there is a fetch plan in effect, then the fetch plan affects the results of this method. All modified fields and all fields in the current fetch plan are unloaded and then fields in the current fetch plan are fetched from the datastore. When I read this before it wasn't clear to me what happens if there is 'no fetch plan' (I don't have a fetch plan in the application I am debugging at the moment). I interpreted the above as indicating that having no fetch plan would mean that the top paragraph would apply: causes all transactional instances to be refreshed and further I assumed that this would include SCOs belonging to those transactional instances (as there's no way to refresh SCOs explicitly with a refresh(Object o) call). ---------------------------------------- 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 |
In a scenario where no fetch groups are configured should: datanucleus.cachecolllections=false be just as effective at making sure one user sees the changes made by another in terms of the elements contained in a collection? ---------------------------------------- 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 |
||
|
|
|
|
Current timezone is GMT May 17, 2012 12:22:06 PM |
