> 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.
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.
>
> 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".
