Hello again.

On further searching, I have found that every field in the meta data is 
flagged as not being cascade_immediate.

So, during the cascadePersist call, nothing is getting single persisted.

Was I supposed to do something to get these set to 'cascade_immediate' 
or is there supposed to be a regular persist call that pushes the whole 
object at once?

Thanks,


Jay

Jay D. McHugh wrote:
> Hello all.
>
> I am trying to persist a test entity into the systemdatabase (derby) 
> in geronimo.
>
> But, it is not working.
>
> I have put lots of debugging into the persist code and what I have 
> found is that the action set in BrokerImpl.persist is 6 (ops_attach) 
> is that what it should be?
>
> Because what is happening is that the process floats down to the point 
> where it checks to see if the state manager is null (// ACT_RUN).  The 
> state manager is null, so it bypasses that whole block of code and 
> falls into the else.
>
> It next checks to see if the PersistenceCapable object (pc) is 
> detached, which it is not - so it grabs the object meta data.
>
> It fires off the beforePersist lifecycle event.
>
> Checks to see if the id is null (which it is) and proceeds to assign 
> it to the appropriate value (I assume it is the appropriate value 
> anyway: org.apache.geronimo.test.jpa.AllFieldTypes-1).
>
> Next it checks to see if the object is cached anywhere (it is not) so 
> it clears the persistenceCapable (pc) statemanager.
>
> Then it creates a new state manager using the calculated id (the id 
> type is application managed) and checks the _flags variable.  It is 
> not 'flag_active' and ends up setting the state manager to 'persistent 
> new non-transactional' and cascades the persist - but never does the 
> persist on the current object.
>
> Is this (rambling explanation the description of) a bug or the way 
> that this is supposed to work for a 'resource_local' persistence unit?
>
> Thanks,
>
> Jay
>
>
> .
>