/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
=========================================================================== 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".
----- 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".
____________________________________________________
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".
