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