Hi We created a JIRA issue which is located at http://jira.codehaus.org/browse/CASTOR-3248
best regards -----Original Message----- From: Justin Case [mailto:[email protected]] Sent: Montag, 29. April 2013 09:55 To: [email protected] Subject: RE: [castor-user] Lazy loaded collections not read-only Hi Werner Thanks for the feedback. Will try to. When we look at the below code (Castor 1.3.1) we see why with lazy loading the collection elements are loaded with access mode "shared". The suggestedAccessMode is passed as null and for this the access mode finally used is then the access mode of the table. This is "shared" here as the table must be accessible for read only operations and read write operations depending on business logic. I am just a bit surprised by the behaviour as this is a major feature and I found no related posts. As such I want to be sure that we are not overlooking something obvious. ------------------------------ org.exolab.castor.persist.LockEngine public void load(final AbstractTransactionContext tx, final OID oid, final ProposedEntity proposedObject, final AccessMode suggestedAccessMode, final int timeout, final QueryResults results, final ClassMolder molder) throws PersistenceException { // mold only if object has not been expanded typeinfo._molder.mold(tx, lock, proposedObject, accessMode); ------------------------------ Called by below method. Parameter suggestedAccessMode is passed as null. As suggestedAccessMode is null accessMode is set to access mode of molder. This is the access mode of the table the collection elements are mapped to. In this code part for the elements in the lazy loaded collections always the access mode of the table is used, so access mode of parent table is ignored. Which is just unexpected. ------------------------------ org.castor.persist.AbstractTransactionContext public final synchronized Object load( final Identity identity, final ProposedEntity proposedObject, final AccessMode suggestedAccessMode, final QueryResults results) throws PersistenceException engine.load(this, oid, proposedObject, suggestedAccessMode, _lockTimeout, results, molder); ------------------------------ Called by below method which loads the collection elements from the id. Parameter suggestedAccessMode is passed as null. ------------------------------ org.castor.persist.proxy.RelationCollection private Object lazyLoad(final Identity ids) ProposedEntity proposedValue = new ProposedEntity(_parent._molder); o = _parent._tx.load(ids, proposedValue, null); ------------------------------ Best regards, Justin -----Original Message----- From: Werner Guttmann [mailto:[email protected]] Sent: Montag, 29. April 2013 09:12 To: [email protected] Cc: [email protected] Subject: Re: [castor-user] Lazy loaded collections not read-only Hi 'user', mind creating a Jira issue at http://jira.codehaus.org/browsse/CASTOR and attach a fully working test case ? Whilst I have not been maintaining Castor JDO for a long time, I should still have some familiarity with that code area. Kind Regards Werner On 26.04.2013 01:33, [email protected] wrote: > Hello list, > > We noticed an unexpected behaviour with Castor 1.3.1 and Castor 1.3.3 RC1. > > We use lazy loading for > collections. When we load an object (the "parent object") in read-only > method the elements ("child objects") in collections for that object > are not read-only. > > That is changes to parent object attributes are not persistent, > changes to the child objects attributes are persistent. > > When we disable the lazy loading for collections the child object are > read-only as expected. > > Is this behaviour actually expected that lazy loaded collections are > not read-only > > even if the parent object is read-only? > > in pseudo code: > ParentPO parentPO = org.exolab.castor.jdo.Database.load > (ParentPO.class, id, Database.READONLY); ChildrenPO childrenPO = > parentPO.getChildren().iterator().next(); //assuming non empty list > parentPO.setParentName("name change"); // change is not persistent > childrenPO.setChildrenName("name change"); // change is persistent > > I hope the attach gives more detailed information. > > > thanks very much for your > attention, best regards > Justin Case > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
