db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Optimization when storing new objects
Date Fri, 06 Feb 2004 14:57:48 GMT
Hi Guillaume,

Guillaume Nodet wrote:

> Armin,
> 
> Thanks a lot for you commit. It works great and this
> reduced by a factor of 3 the time spent in storing
> my objects in database.

Nice to hear!
Hope there will be no negative side-effects ;-)
Thanks for your great suggestions.

regards,
Armin

> 
> Regards,
> Guillaume Nodet
> 
> -----Message d'origine-----
> De : Armin Waibel [mailto:arminw@apache.org]
> Envoye : vendredi 6 fevrier 2004 12:33
> A : OJB Developers List
> Objet : Re: Optimization when storing new objects
> 
> 
> Hi Guillaume,
> 
> Guillaume Nodet wrote:
> 
>>I'm not sure what you mean by 'null' pk fields.
> 
> 
> If one of the declared PK fields of the given object represents
> 'null' (non primitive field value null, primitive number field value 0)
> we know that the given object is new and we don't need further checks
> (e.g. we don't try to materialize this object).
> 
> <snip PB upcoming fix, line 664>
> boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
> Identity oid = new Identity(obj, this, cld);
> if (!doInsert)
> {
>     doInsert = objectCache.lookup(oid) == null
>          && !serviceBrokerHelper().doesExist(cld, oid, obj);
> }
> </snip>
> 
> regards,
> Armin
> 
> 
>>But i'm using the SequenceManagerHighLowImpl to be
>>database agnostic. So the pk fields are
>>generated when constructing the Identity object.
>>
> 
> 
> 
> 
> 
>>Regards,
>>Guillaume
>>
>>-----Message d'origine-----
>>De : Armin Waibel [mailto:arminw@apache.org]
>>Envoye : jeudi 5 fevrier 2004 14:48
>>A : OJB Developers List
>>Objet : Re: Optimization when storing new objects
>>
>>
>>Hi,
>>
>>Guillaume Nodet wrote:
>>
>>
>>
>>>I do understand the problem.
>>>But i ran my program under quantify, and i indeed 70% of the
>>>time used to store my objects are used trying to materialize
>>>inexistant objects...
>>>
>>>In the store(Object obj) method of PersistentBrokerImpl, an
>>>Identity object is created, just before looking in cache or
>>>trying to materialize object. When this identity is created
>>>it may ask for a unique value to the serviceSequenceManager.
>>>In this case, the object is sure not to be in database.
>>>Could this information be brought back to the PersistentBroker
>>>so that it does not try to make a cache lookup and materialize ?
>>>
>>
>>
>>ah, now it's clear. I will try to "fix" this.
>>Think an additional helper method can check for 'null'
>>PK fields.
>>
>>regards,
>>Armin
>>
>>
>>
>>>Guillaume
>>>
>>>-----Message d'origine-----
>>>De : Armin Waibel [mailto:arminw@apache.org]
>>>Envoye : jeudi 5 fevrier 2004 11:30
>>>A : OJB Developers List
>>>Objet : Re: Optimization when storing new objects
>>>
>>>
>>>Hi Guillaume,
>>>
>>>Guillaume Nodet wrote:
>>>
>>>
>>>
>>>
>>>>When inserting new objects in the database, would it be possible to avoid
>>>>trying to materialize them ?
>>>>For example when storing an object in ojb, ojb first tries to materialize
>>>>it.
>>>>If this fails, ojb passes true in the 'insert' parameter to the storeToDb
>>>>method.
>>>>This parameter is given to the storeCollections method, but when
>>>
>>>collections
>>>
>>>
>>>
>>>>are 1-n
>>>>with cascade store on, the parameter is not given to the store method.
>>>
>>>
>>>Think this is because we don't know whether or not the reference objects
>>>needs 'insert' or 'update'.
>>>
>>>regards,
>>>Armin
>>>
>>>
>>>
>>>
>>>>Would it be possible to call the store(Object obj, Identity oid,
>>>>ClassDescriptor cld, boolean insert)
>>>>instead to avoid trying to materialize the object when we know that is
>>>
>>>does
>>>
>>>
>>>
>>>>not exists ?
>>>>
>>>>Regards,
>>>>
>>>>Guillaume
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message