See below.
-----Original Message-----
From: Sachin Aggarwal <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, October 08, 1999 8:52 PM
Subject: Re: finder methods specifications
>> Absolutely! The finder should be able to find the entities that were
>> previously created by the same transaction.
>
>Remember we are talking about not only finding the entity but finding it in
>the right state. The specs currently allow this to be violated.
>
>> The incorrect transactional semantics in your server will also cause
>> surprising results when you don't use finder methods.
>
>Except that in that scenario you know that if you have not done a check
>point the query from the database won't give you the latest state.
>
>> however, your "fixes" should not be "guidelines" for EJB usage or EJB
spec
>corrections.
>
>Rememebr findByPrimaryKey does do what we want - it gives you the entity in
>the latest state(atleast in some ejb servers) whereas a call to the
database
>call to look up that entity wouldn't give you the latest state. So
>findByPrimaryKey works differently than other finders as far as
>transactional semantics are concerned.
Let me understand this. You start a transaction, do some processing on some
beans and then you call a finder method. Are you saying that the state of
the returned bean depends on which finder you used? I certainly doubt that
such an ambiguity would be intentional in the spec or would be a useful
"feature" of any implementation.
>I feel the spec should clarify that since there's nothing like
>getTransaction().performCheckpoint( ) or ejbStoreTransactionState() - that
>one really needs to be vary of using finders other than findByPrimaryKey.
The semantic ambiguity you are talking about here is caused by your server's
implementation and it is not a spec issue. While it is fine for a server to
have documented implementation-driven limitations (such as "no finders other
than findByPrimaryKey should be used inside a transaction"), the spec itself
should not be littered with such inconsistencies.
Imre Kifor
Valto Systems
>> -----Original Message-----
>> From: Sachin Aggarwal <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> Date: Friday, October 08, 1999 6:09 PM
>> Subject: Re: finder methods specifications
>>
>>
>> >> This is a pure server implementation issue. If the effects of
>> >> changes made
>> >> early on in a transaction are not visible later in the same
>> >> transaction then
>> >> we cannot talk about a semantically correct transactional
>> >> system. Caching,
>> >> "smart" server implementations or application design
>> should under no
>> >> circumstances affect the transactional semantics of the underlying
>> >> architecture.
>> >
>> >I lost you there. Are you saying that the finder should give
>> results which
>> >reflect the latest state ?
>> >
>> >>
>> >> Muddying the EJB spec with gotchas and other
>> implementation dependent
>> >> exceptions will only weaken the architecture. There is no
>> >> reason for the
>> >> spec to disallow finder methods that need to return entities
>> >> created in the
>> >> same transaction.
>> >>
>> >> Imre Kifor
>> >> Valto Systems
>> >>
>> >> -----Original Message-----
>> >> From: Chia-ming Hsu <[EMAIL PROTECTED]>
>> >> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> >> Date: Friday, October 08, 1999 4:04 PM
>> >> Subject: Re: finder methods specifications
>> >>
>> >>
>> >> >Hi,
>> >> >
>> >> >I am still not convinced that this is a spec or server
>> implementation
>> >> issue.
>> >> >I think this is something about the application design. The
>> >> key point is
>> >> >when do you seperate different business processes into different
>> >> >transactions properly.
>> >> >
>> >> >I agree with Rickard that there won't be good cases that a
>> >> finder method
>> >> >should be used to look up entities including those just
>> >> created in the SAME
>> >> >transaction. There will be disasters if something goes
>> >> wrong in the big
>> >> >transaction and it got rolled back. Imagine in Sachin's
>> >> example of monthly
>> >> >financial report, where the last financial record and the
>> >> monthly report
>> >> >generation are put into one transaction. If after the
>> >> monthly report is
>> >> >sent out, and for some reasons the entire transaction fails
>> >> and is rolled
>> >> >back, and the last financial record is rolled back as
>> well, then the
>> >> >recipient of the monthly report will have an extra financial
>> >> record on his
>> >> >report that is actually not in the record.
>> >> >
>> >> >Different business processes should not be put into one big
>> >> transaction.
>> >> >That is an application design problem. I wonder how the
>> new WebLogic
>> >> >feature actually works if the server update the database
>> BEFORE the
>> >> >transaction is committed.
>> >> >
>> >> >By the way, one client call can trigger multiple
>> transactions on the
>> >> >server-side, so that we don't need a seperate client call.
>> >> >
>> >> >
>> >> >Chia-ming Hsu
>> >> >Sight Software, Inc.
>> >> >
>> >> >
>> >> >
>> >> >-----Original Message-----
>> >> >From: Sachin Aggarwal <[EMAIL PROTECTED]>
>> >> >To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> >> >Date: Friday, October 08, 1999 12:00 PM
>> >> >Subject: Re: finder methods specifications
>> >> >
>> >> >
>> >> >>I think Wolf puts across the point well.
>> >> >>
>> >> >>In the EJB environment, if the container is given the power
>> >> to shield
>> >> state
>> >> >>change from the persistence store by being given the
>> >> flexibility to call
>> >> >>ejbStore at will, then it is it's responsibility to be
>> able to give
>> >> >>semantically correct results when queried based on the state.
>> >> >>
>> >> >>It's not fair for a container to not update the database
>> >> with changed
>> >> >values
>> >> >>and keep it in memory but then when queried based on the
>> >> state look up the
>> >> >>database only instead of looking within itself.
>> >> >>
>> >> >>To answer Rickards question, I've hit across this
>> scenario where the
>> >> server
>> >> >>side transaction executes several pieces of business logic
>> >> and at times
>> >> the
>> >> >>business logic being executed in the later part of the
>> >> transaction looks
>> >> up
>> >> >>entities that were created in the earlier part of the
>> transaction.
>> >> >>
>> >> >>It could be the client adds an order item to an order and
>> >> as part of this
>> >> >>method on the session bean
>> >> >>the order is asked to recalculate it's cost and it uses a
>> >> finder method to
>> >> >>find all it's order items.(Let's not go into dependent
>> >> objects please:-)
>> >> >>
>> >> >>It could be that a last financial transaction has been
>> >> posted for the
>> >> month
>> >> >>and the monthly pricing rule is looking up all transactions
>> >> posted in that
>> >> >>month and summarizing them and sending out a reporting
>> >> email. In some
>> >> cases
>> >> >>as this, one could argue that the client could invoke a
>> >> seperate method to
>> >> >>create the summary. The workflow and what events are fired
>> >> on what action,
>> >> >>are part of our server logic and we don't want to be forced
>> >> to move this
>> >> >>logic to our client as a seperate call.
>> >> >>
>> >> >>I think this is a pretty simple issue and when I brought it
>> >> up with our
>> >> ejb
>> >> >>server vendor( weblogic) - I was told they were fixing it.
>> >> Now they have a
>> >> >>delay_update property that can be set to false and then the
>> >> database will
>> >> >be
>> >> >>in synch with the memory all the time .
>> >> >>I don't like the solution of hitting the database for every
>> >> settor and was
>> >> >>hoping to find a better solution.
>> >> >>
>> >> >>I'm keen on knowing if there are vendors that have solved
>> >> this problem but
>> >> >I
>> >> >>guess vendors need to see this as a problem first.
>> >> >>
>> >> >>
>> >> >>> -----Original Message-----
>> >> >>> From: A mailing list for Enterprise JavaBeans development
>> >> >>> [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Lewis
>> >> >>> Sent: Friday, October 08, 1999 8:42 AM
>> >> >>> To: [EMAIL PROTECTED]
>> >> >>> Subject: Re: finder methods specifications
>> >> >>>
>> >> >>>
>> >> >>> Wolf Siberski wrote:
>> >> >>>
>> >> >>> > I don't know if this is the expected result as specified by
>> >> >>> > the EJB spec (I suspect that this is a specification hole),
>> >> >>> > but I would not call that result "correct".
>> >> >>> >
>> >> >>> > In "design-by-contract"-speak: findByName( name ) has the
>> >> >>> > following postcondition: for each entity in the
>> result set the
>> >> >>> > expression "result.getName().equals( name )" evaluates
>> >> to "true".
>> >> >>>
>> >> >>> This may be true. However, the post-condition only holds
>> >> >>> _after the method has
>> >> >>> completed_, at which time the results will be written to the
>> >> >>> database, since we
>> >> >>> are talking about container managed transactions, here (I
>> >> >>> would consider method
>> >> >>> completion to include the container's work of writing the
>> >> >>> changes). Before the
>> >> >>> method is complete, the the post-condition will not hold.
>> >> >>>
>> >> >>> > No. The responsibility of "findByName" is to return all
>> >> >>> > entities with the specified name. If that can't be fulfilled
>> >> >>> > for implementation reasons (and I understand the
>> implementation
>> >> >>> > problems well), the spec should at least state that
>> >> >>> > "calling finder methods after modifications of entity
>> >> >>> > beans in the same transaction yields undefined results"
>> >> >>> > or something like that.
>> >> >>>
>> >> >>> Perhaps this statement should be made as supplemental
>> >> >>> information, but the spec
>> >> >>> certainly does indicate that this will be the behavior, as it
>> >> >>> clearly describes
>> >> >>> the behavior of container-managed transactions. This is not
>> >> >>> a container
>> >> >>> implementation issue; it is an issue with the application.
>> >> >>>
>> >> >>> -Kevin
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>============================================================
>> >> ==============
>> >> =
>> >> >>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".
>> >>
>> >>
>> >
>> >=============================================================
>> ==============
>> >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".
>
>
===========================================================================
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".
