Also, identity doesnt mean primary keys. The identity comes into existence
when container creates ejbObject and associates it with bean instance for
that primary key. Returning remote reference doesnt mean that its ready to
be called. This is hidden from the client, and the behaviour is
configurable as the example below. But ofcourse client will not see any
difference in either case.
/Ashwani
>-----Original Message-----
>From: Sonal Patni [mailto:sonal.patni@(protected)]
>Sent: Friday, September 19, 2003 10:52 AM
>To: J2EEPATTERNS-INTEREST@(protected)
>Subject: Re: Large finders on entity beans refactored
>
>
>Abstract from weblogic site ==>
>http://dev2dev.bea.com/technologies/ejb/articles/196.jsp
>_______________________________________________________________
>_________
>__
>The CMP Advantage -- Finders Loading Beans
>
>Like business methods, entity bean finder performance depends
>on setting
>and using transactions appropriately. Let's consider another example
>with our Employee Bean.
>
> Collection employees =
> home.findEmployeesWithSalariesGreaterThan(30000);
> Iterator it = employees.iterator();
> while (it.hasNext()) {
> Employee e = (Employee) it.next();
> double salary = e.getSalary();
> }
>
>This simple example executes a finder (database query) to return
>employees whose salary is greater than the passed parameter, in this
>case 30,000. It then iterates through this collection and retrieves the
>salary from each. In the case where N employees are returned from the
>finder, this example does N+1 database hits. The finder hits the
>database and each of the subsequent getSalary call-backs hits the
>database.
>
>By now, you've probably guessed that we'll try to execute the
>finder and
>the getSalary methods within a single transaction. Now, how many
>databases accesses will occur? The answers may surprise you.
>
>If Employee is a CMP entity bean and the finder and subsequent
>getSalary
>methods occur in the same transaction, there can be one
>database access.
>The finder executes a select query which loads the associated primary
>keys and the other Employee fields. These prefetched beans are entered
>into the EJB cache and the getSalary method calls read
>directly from the
>memory cache. This is the finders-load-bean option in the
>weblogic-ejb-jar.xml. It is enabled by default, and it allows
>finders to
>prefetch additional data into the EJB cache. In this common case, it
>reduces the database access from N+1 to just 1.
>
>What if the Employee is a BMP entity bean? It may surprise you, but
>there will still be N+1 database hits. The BMP entity bean will
>implement an ejbFindEmployeesWithSalariesGreaterThan method in the bean
>class to return a Collection of primary keys to the container, but it
>cannot prefetch into the cache. Each getSalary call then produces an
>ejbLoad call and another database hit.
>
>Finders prefetching beans is a big performance advantage of CMP, and in
>general CMP (especially EJB 2.0's CMP) entity beans outperform BMP
>entity beans.
>
>_______________________________________________________________
>_________
>__
>
>Now check http://e-docs.bea.com/wls/docs61/ejb/reference.html
>and search
>for finders-load
>
>finders-load
>
>
>Range of values:
> true | false
>
>Default value:
> true
>
>Requirements:
> Optional element. Valid only for CMP entity EJBs.
>
>Parent elements:
> weblogic-enterprise-bean,
>entity-descriptor,
>persistence
>
>Deployment file:
> weblogic-ejb-jar.xml
>
>Function
>
>The finders-load-bean element determines whether WebLogic Server loads
>the EJB into the cache after a call to a finder method returns a
>reference to the bean. If you set this element to true, WebLogic Server
>immediately loads the bean into the cache if a reference to a bean is
>returned by the finder. If you set this element to false, WebLogic
>Server does not load automatically load the bean into the cache until
>the first method invocation; this behavior is consistent with the EJB
>1.1 specification.
>
>
>HTH
>Sonal
>
>
>-----Original Message-----
>From: Alok_Band [mailto:Alok_Band@(protected)]
>Sent: Friday, September 19, 2003 10:43 AM
>To: J2EEPATTERNS-INTEREST@(protected)
>Subject: Re: Large finders on entity beans refactored
>
>
>Container has to construct remote objects for all returned rows so
>container has to get all the identies (i.e. Primary Keys). And it is
>linked with remote object by "EntityContext" which is sent to your Bean
>class when it is associated with any EJB Object.
>
>On the statement,
>"It doesnt give identity till there is request by client. But there is
>cost of construction of Remote interfaces that it return to the client
>for multi object finders."
>
>From this I understand that Bean objects are not associated with remote
>unless there request by client. But remote object do have associated
>"Identity" i.e. EntityContext.
>
>Thanks,
>Alok
>
>
>> -----Original Message-----
>> From: Pradeep Kumar [SMTP:pradeepk@(protected)]
>> Sent: Friday, September 19, 2003 9:58 AM
>> To: J2EEPATTERNS-INTEREST@(protected)
>> Subject: Re: Large finders on entity beans refactored
>>
>> To me the specs statement contradicts the behavior of the finder
>> methods. The very purpose of finding is to first get all the
>> identities (primary keys), so now that you have the identities, how
>> could the container not keep them in the ready state and loose the
>> object identities (pooled state do not have any identities).
>>
>> I don't get it when you say that the identity is not given to the
>> objects until the client has requested. Where and how else the
>> identities are maintained by the container?
>>
>> -----Original Message-----
>> From: Kalra, Ashwani [mailto:ashwani.kalra@(protected)]
>> Sent: Friday, September 19, 2003 9:54 AM
>> To: J2EEPATTERNS-INTEREST@(protected)
>> Subject: Re: Large finders on entity beans refactored
>>
>> Here is what specs says
>> "After the ejbFind<METHOD>(...) method completes, the
>instance remains
>
>> in the pooled state. The container may, but is not required to,
>> immediately activate the objects that were
>> located by the finder using the transition through the ejbActivate()
>> method. " Section 10.5.3 page no 177 of EJB 2.0
>>
>> It doesnt give identity till there is request by client. But
>there is
>> cost of construction of Remote interfaces that it return to
>the client
>
>> for multi object finders. HTH
>> /Ashwani
>>
>>
>> -----Original Message-----
>> From: Pradeep Kumar [mailto:pradeepk@(protected)]
>> Sent: Friday, September 19, 2003 9:30 AM
>> To: J2EEPATTERNS-INTEREST@(protected)
>> Subject: Re: Large finders on entity beans refactored
>> While the container is executing the finder method, it must give
>> identities to each of the objects (primary keys). Hence,
>they must be
>> placed in the ready state, since objects do not have any identity in
>> the pooled state.
>>
>> Can someone please clarify the statement from the specs.
>>
>> -----Original Message-----
>> From: Kalra, Ashwani [mailto:ashwani.kalra@(protected)]
>> Sent: Thursday, September 18, 2003 7:28 PM
>> To: J2EEPATTERNS-INTEREST@(protected)
>> Subject: Re: Large finders on entity beans refactored
>>
>> Here what I read from specs 2.0
>>
>> "The instance does not move to the ready state during the
>execution of
>
>> a finder or a home method."
>> -----Original Message-----
>> From: Pradeep Kumar [mailto:pradeepk@(protected)]
>> Sent: Monday, September 15, 2003 9:54 AM
>> To: J2EEPATTERNS-INTEREST@(protected)
>> Subject: Re: Large finders on entity beans refactored
>> I totally agree. We are told that if we read a large amt of data via
>> entity beans, there will be too many entity objects in ready state.
>One
>> can argue, that they will be the cached data for subsequent reads
>(lets'
>> say via find by primary key), however, to avoid dirty reads, the
>container
>> calls the EJB load method, which defeats the purpose of caching
>>
>> -----Original Message-----
>> From: Katz Guy [mailto:Guy_Katz@(protected)]
>> Sent: Sunday, September 14, 2003 12:12 PM
>> To: J2EEPATTERNS-INTEREST@(protected)
>> Subject: Large finders on entity beans refactored
>>
>> Hi;
>> Going through the core patterns book.
>> There is a bad practice dedicated to not using finder methods when
>> large result is expected but use a DAO instead. My understanding is
>> that the authors want to have a 'dual interface' for access to the
>> same data, Modeling the data itself as entity beans yet
>using DAO for
>> the search. Is this correct? If so, wouldn't this be in contrast to
>> resusability? Also, isnt this a good place to put your money
>on vendor
>
>> container optimiations? _______________________
>> Guy Katz
>> Software Architect, CAP-IFS
>> Comverse
>> guy.katz@(protected)
>> +972 3 7663686
>> DISCLAIMER:
>> This message (including attachment if any) is confidential
>and may be
>> privileged. Before opening attachments please check them for viruses
>> and defects. MindTree Consulting Private Limited (MindTree) will not
>> be responsible for any viruses or defects or any forwarded
>attachments
>
>> emanating either from within MindTree or outside. If you
>have received
>
>> this message by mistake please notify the sender by return
>e-mail and
>> delete this message from your system. Any unauthorized use or
>> dissemination of this message in whole or in part is strictly
>> prohibited. Please note that e-mails are susceptible to change and
>> MindTree shall not be liable for any improper, untimely or
>incomplete
>> transmission.
>> ====================================================================
>> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
>> http://java.sun.com/blueprints/corej2eepatterns List Archive:
>> http://archives.java.sun.com/archives/j2eepatterns-interest.html
>> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
>> listserv@(protected)
>> ====================================================================
>> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
>> http://java.sun.com/blueprints/corej2eepatterns List Archive:
>> http://archives.java.sun.com/archives/j2eepatterns-interest.html
>> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
>> listserv@(protected)
>> DISCLAIMER:
>> This message (including attachment if any) is confidential and may be
>> privileged. Before opening attachments please check them for viruses
>and
>> defects. MindTree Consulting Private Limited (MindTree) will not be
>> responsible for any viruses or defects or any forwarded attachments
>> emanating either from within MindTree or outside. If you
>have received
>> this message by mistake please notify the sender by return e-mail and
>> delete this message from your system. Any unauthorized use or
>> dissemination of this message in whole or in part is strictly
>prohibited.
>> Please note that e-mails are susceptible to change and MindTree shall
>not
>> be liable for any improper, untimely or incomplete transmission.
>> ____________________________________________________
>> 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.
>> ====================================================================
>> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
>> http://java.sun.com/blueprints/corej2eepatterns List Archive:
>> http://archives.java.sun.com/archives/j2eepatterns-interest.html
>> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
>> listserv@(protected)
>> ====================================================================
>> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
>> http://java.sun.com/blueprints/corej2eepatterns List Archive:
>> http://archives.java.sun.com/archives/j2eepatterns-interest.html
>> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
>> listserv@(protected)
>> DISCLAIMER:
>> This message (including attachment if any) is confidential and may be
>> privileged. Before opening attachments please check them for viruses
>and
>> defects. MindTree Consulting Private Limited (MindTree) will not be
>> responsible for any viruses or defects or any forwarded attachments
>> emanating either from within MindTree or outside. If you
>have received
>> this message by mistake please notify the sender by return e-mail and
>> delete this message from your system. Any unauthorized use or
>> dissemination of this message in whole or in part is strictly
>prohibited.
>> Please note that e-mails are susceptible to change and MindTree shall
>not
>> be liable for any improper, untimely or incomplete transmission.
>>
>> ____________________________________________________
>> 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.
>> ====================================================================
>> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
>> http://java.sun.com/blueprints/corej2eepatterns List Archive:
>> http://archives.java.sun.com/archives/j2eepatterns-interest.html
>> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
>> listserv@(protected)
>> ====================================================================
>> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
>> http://java.sun.com/blueprints/corej2eepatterns List Archive:
>> http://archives.java.sun.com/archives/j2eepatterns-interest.html
>> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
>> listserv@(protected)
>***************************************************************
>*********
>**
>This email (including any attachments) is intended for the sole use of
>the intended recipient/s and may contain material that is CONFIDENTIAL
>AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or
>copying or distribution or forwarding of any or all of the contents in
>this message is STRICTLY PROHIBITED. If you are not the intended
>recipient, please contact the sender by email and delete all copies;
>your cooperation in this regard is appreciated.
>***************************************************************
>*********
>**
>
>====================================================================
>Companion Site: http://www.corej2eepatterns.com
>J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
>List Archive:
>http://archives.java.sun.com/archives/j2eepatterns-interest.html
>Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
>listserv@(protected)
>
>====================================================================
>Companion Site: http://www.corej2eepatterns.com
>J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
>List Archive:
>http://archives.java.sun.com/archives/j2eepatterns-interest.htm
l
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
____________________________________________________
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.
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
