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