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