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