DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Key: NUCCORE-562
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Eric Sultan
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
DataNucleus Core

Create a "Stateless" PersistenceManager that ignore dirty checks, callbacks and cascading

Created: 20/Sep/10 02:10 PM   Updated: 31/Oct/11 11:18 AM   Resolved: 18/Jun/11 09:33 AM
Component/s: None
Affects Version/s: None
Fix Version/s: 3.0.0.m6

 Description  « Hide
The idea is to create an access to the PM that allow to create, update or delete many object as fast as possible, without checking the consistency.

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 06/Oct/10 02:00 PM
Perhaps the user had in mind something like this

In the case of DataNucleus, we would not have some "other mode" of operation but simply provide flags to turn off particular features. So L1 cache, reachability, dirty checks. Then when we allow "persistence profiles" we can automate the selection of such persistence properties

Andy Jefferson added a comment - 01/Mar/11 05:59 PM
To help this case also consider the following:-

We currently have a StateManager that manages a single object. If we had a StateManager that had only some of its capabilities, but that could be used for all objects then we would be better set up to handle bulk operations.

For example a user wants to persist X objects where X is large. We currently create a StateManager for each object. The user doesn't care for the majority of the StateManagers capabilities, and is getting X StateManagers created just to persist their objects. Instead if we had the BulkStateManager then when persisting X objects we only create 1 BulkStateManager and it simply gets the field values from the objects to be persisted.

Andy Jefferson added a comment - 08/Mar/11 07:38 PM
We can now (SVN trunk) turn off
* L1 cache - "datanucleus.cache.level1.type=None"
* L2 cache - "datanucleus.cache.level2.type=None"
* detachOnClose, detachAllOnCommit, detachAllOnRollback
* pbrAtCommit
* managedRelations

Still need to enable turning off of cascade operations, and enabling of an optimised flush() for RDBMS (since in that situation there is no referential integrity consideration)

Andy Jefferson added a comment - 15/Mar/11 02:45 PM
Can now turn off callbacks/listeners by setting persistence property "datanucleus.allowCallbacks" to false.

Andy Jefferson added a comment - 18/Jun/11 09:33 AM
Other than what is already done, the only other item that could be done is NUCCORE-675 that would involve marking a PM as creating a particular type of StateManager that would not manage particular information, so bulk operations could be done fast(er). Without a particular persistent model to work off and understand the exact requirements I don't see how more can be done

Ales Justin added a comment - 31/Oct/11 01:33 AM
But wouldn't this mean - using the properties - that you're then stuck with this behavior through-out your app?
e.g. where Hibernate's Stateless session is on-demand (per usage / invocation).

Andy Jefferson added a comment - 31/Oct/11 08:33 AM
The PM can accept properties too (and hence one PM for bulk changes is easily possible); may need some minor updates to accept (all of) those properties, but then this project is open source, and anyone interested can easily contribute updates. Obviously since you're a Hibernate developer then why this is of interest to you is not clear ...

Ales Justin added a comment - 31/Oct/11 11:18 AM
>> Obviously since you're a Hibernate developer then why this is of interest to you is not clear ...

Not really a Hibernate developer. ;-)

I have a generic "framework", abstracting away the usage of GAE vs. JEE.
Stateless batch handling is definitely useful, hence I want to expose this "stateless" API as generic,
while having custom adapters for diff ORM solutions; GAE -> DataNucleus, JEE (e.g. JBossAS) --> Hibernate, etc.

Hopefully I can find some spare time to have a closer look at the code ...