As an application developer we have found this 'feature' quite unwelcome as
it requires a deep copy (clone) be made whenever a bean attribute is
accessed in order to guarantee data integrity across multiple threads. Doing
otherwise requires an unrealistically high degree of foreknowledge as to how
a bean may be used by some future developer. For production systems, as
opposed to benchmarking exercises, data integrity is usually considered more
important than performance.
Note that given that we were unable to identify a reliable mechanism to
determine if the caller were local or remote the results has been that both
a clone and a serialization occurs for remote users - which is definitely a
performance hit!
Hopefully the EJB reference implementation will clarify the right and wrong
of this and other similar issues...
regards,
Donald.
PS Our beans are coarse-grained.
> -----Original Message-----
...
> One of the app servers performs an "optimization" that breaks the
> application in many different ways. This server optimizes intra-vm bean
> invocations by changing the semantics of the bean method from
...
>
> Chip Wilson
> ObjectSpace
>
===========================================================================
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".
