test
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Ian McCallion
> Sent: 14 October 1999 10:56
> To: [EMAIL PROTECTED]
> Subject: Re: finder methods specifications
>
>
> Philip Aston wrote:
>
> > In any transaction, including distributed ones, you should see the
> > committed state plus the effects of changes made earlier within the
> > same transaction. Outside the transaction you should only see the
> > committed state.
>
> Agree 100%. But only if we can agree to exclude the examples Chip
> Wilson pointed
> out where two beans of different classes instantiate the same
> database data. If
> we exclude these situations, we are saying that for the duration of a
> transaction, a bean's state is pure WORKING STORAGE which seems emminently
> reasonable to me. If we insist on including them then:
>
> 1. A change in state of bean A (say) could cause a change in
> state of bean B
> without a method of bean B being called - thus violating the
> encapsulation rule.
>
> 2. The implementation if this would involve loading and storing
> the entire bean
> state for every method call thus killing performance.
>
> 3. Whenever bean A changes state any validation of the data
> already performed by
> bean B would be nullified, so making it pointless to validate the data.
>
> In other words encompassing Chip's examples within your consistency rule
> violates encapsulation, performs like a dog and is useless to the
> developer.
> (Flogging ended. Is the horse dead yet;-)
>
> > The behaviour clearly requires a lot of ejbStore/ejbLoads to ensure
> > correct behaviour and consequently efficient implementations need very
> > tight intergration between the EJB server and database. There are
> > clear potential efficiency speed-ups if, for example, a container
> > knows it has exclusive access to a database.
>
> Disagree. Taking away Chip's examples, there is no need to do lots of
> ejbStore/ejbLoads. Correct behaviour is achieved if finders edit
> (i.e. add and
> delete beans from) their results based on the beans that are
> already involved in
> the transaction.
>
>
> Ian McCallion
> CICS Business Unit
> IBM Hursley
> [EMAIL PROTECTED]
> Tel: ++44-1962-818065
> Fax: ++44-1962-818069
>
> ==================================================================
> =========
> 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".
