Re: Performance for Finders

The app server will only need to send sql to the database when the object is
not in the cache. An update of the (none-identity) properties will be a cost
of the updating transaction ­ not the call to the findByprimaryKey. Well, at
the end it depends on the synchronization mechanism chosen by the app server
vendor, but it is very likely that an entity found in the cache by a call to
findByPrimaryKey will be in synch, or will have to wait for parallell
tranactions to complete ­ depending on level and whether the caller is in a
transaction. 

/Johan

Den 03-08-08 08.52, skrev "Kalra, Ashwani" <[email protected]>:

> Even then why it picks up from cache. Somebody might be changing that record ?
> ~~~~~~~~~~~~~~~~~~~~
> Cheers
> Ashwani Kalra
> <http://www.geocities.com/ashwani_kalra>
> ~~~~~~~~~~~~~~~~~~~~
>>  
>> -----Original Message-----
>> From: Vikram Naik  [mailto:[email protected]]
>> Sent: Thursday, August 07, 2003  6:04 PM
>> To: Kalra, Ashwani;  [email protected]
>> Subject: Re: Performance for  Finders
>> 
>>  
>> May be as the primary key can have only two  cases.
>>  
>>  
>>  
>> Case 1: It exists.
>>  
>> Case 2: It doesn't.
>>  
>>  
>>  
>> Its not subject to change or being  updated.
>>  
>>  
>>  
>> Vikram Naik 
>>  
>>>  
>>> ----- Original Message -----
>>>  
>>> From:  Kalra,  Ashwani <mailto:[email protected]>
>>>  
>>> To: [email protected]
>>>  
>>> Sent: Thursday, August 07, 2003 6:08  AM
>>>  
>>> Subject: Re: Performance for  Finders
>>>  
>>> 
>>>  
>>> Please ignore the earlier mails from me on this subject.
>>>  
>>>  
>>>  
>>>  
>>> This  requirement does not apply to the ejbFindByPrimaryKey method..... "
>>>  
>>> This raises  further curiousity!!    Why  ?
>>>  
>>>  
>>>  
>>> /Ashwani
>>>  
>>>  
>  
>>  
>> -----Original Message-----
>> From: Vikram Naik  [mailto:[email protected]]
>> Sent: Wednesday, August 06,  2003 9:17 PM
>> To: [email protected]
>> Subject:  Re: Performance for Finders
>> 
>>  
>> Hello ,
>>  
>>  
>>  
>> Johan is right by saying   "Custom finders will always require a database
>> roundtrip (most app servers) even if the resulting row already has a
>> representation in the cache".
>>  
>>  
>>  
>> As said in the specs for EJB  2.1 under  section "10.5.3 Container's View"
>> 
>> "public <primary key type or collection> ejbFind<METHOD>(...);
>  
> .... The container  invokes the ejbFind<METHOD> method on an instance when a
> client  invokes a matching find<METHOD> method on the  entity bean's home
> interface.
>  
> The container must  pick an instance that is in he pooled state (i.e., the
> instance is not associated with any entity object  identity) for the execution
> of the ejbFind<METHOD>  method.
>  
> If there is no  instance in the pooled state, the container creates  one and
> calls he setEntityContext method on the  instance before dispatching the
> finder method. ......
>  
>  
>  
> Before  invoking the ejbFind<METHOD> method, the container must first
> synchronize the state of those entity bean instances by  invoking the ejbStore
> method on  them. 
>  
> This  requirement does not apply to the ejbFindByPrimaryKey method..... "
>  
>  
>  
> This means there can be  difference in performance between the customFinders
> and  findByPrimaryKey methods
>  
> As that the container has to/needs to  sync the states of all the beans by
> invoking ejbStore method, which  amounts to database roundtrip
>  
>  
>  
> thanks &  regards,
>  
> Vikram Naik
>  
>>  
>> ----- Original Message -----
>>  
>> From:  Johan Eltes <mailto:[email protected]>
>>  
>> To: [email protected]
>>  
>> Sent: Wednesday, August 06, 2003  3:28 PM
>>  
>> Subject: Re: Performance for  Finders
>>  
>> 
>> findByPrimayKey  allows the app server to pick the  object from an entity
>> cache without a roundtrip to the database. Custom  finders will always
>> require a database roundtrip (most app servers) even  if the resulting row
>> already has a representation in the cache.
>> 
>> /Johan
>> 
>> Den 03-08-06  10.05, skrev "Vikram Naik" <[email protected]>:
>> 
>>  
>>> Hello  All,
>>> 
>>>    Is there a performance difference between  the findByPrimayKey and
>>> customFinders ?
>>> 
>>> Ofcourse the  performance of the custom finders will depend on the query,
>>> but fot  this case we can consider the query of the custom finders will be
>>> as  simple as that of the findByPrimaryKey!!
>>> 
>>> Please  comment.
>>> 
>>> TIA,
>>> Vikram Naik
>>> ===========================================================================
>>> To unsubscribe, send email to [email protected] and include in the  body
>>> of the message "signoff EJB-INTEREST".  For general help,  send email to
>>> [email protected] and include in the body of the  message "help".
>>> 
>>> 
>> 
>> ===========================================================================
>> To unsubscribe, send email to [email protected] and include in the  body
>> of the message "signoff EJB-INTEREST". For general help, send email  to
>> [email protected] and include in the body of the message "help".
>> 
> ===========================================================================
> To unsubscribe, send email to [email protected] and include in the  body
> of the message "signoff EJB-INTEREST". For general help, send email  to
> [email protected] and include in the body of the message "help".
> 
> 
>  
> 
> ____________________________________________________
>  
> 
> This message contains information that may be  privileged or confidential and
> is the property of the Cap Gemini Ernst &  Young Group. It is intended only
> for the person to whom it is addressed. If  you are not the intended
> recipient, you are not authorised to read, print,  retain, copy, disseminate,
> distribute, or use this message or any part  thereof. If you receive this
> message in error, please notify the sender  immediately and delete all copies
> of this  message.
> ===========================================================================
> To unsubscribe, send email to [email protected] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [email protected] and include in the body of the message "help".
> 
> 
> 
> ____________________________________________________
> 
> This message contains information that may be privileged or confidential and
> is the property of the Cap Gemini Ernst  Young Group. It is intended only for
> the person to whom it is addressed. If you are not the intended recipient, you
> are not authorised to read, print, retain, copy, disseminate, distribute, or
> use this message or any part thereof. If you receive this message in error,
> please notify the sender immediately and delete all copies of this message.
> =========================================================================== To
> unsubscribe, send email to [email protected] and include in the body of
> the message "signoff EJB-INTEREST".  For general help, send email to
> [email protected] and include in the body of the message "help".
> 
> 



===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".