I believe that the EJB 1.1 restrictions regarding argument passing semantics
are well thought out and following them will be absolutely necessary when
building robust and maintainable solutions. I also agree that pass-by-value
semantics applied to non-primitive Java types is hugely inefficient and will
have to be avoided in any serious production system.
Providing an efficient and scalable entity bean architecture that supports
the use of low granularity entity beans seems to be the best strategy to
solve the above contradicting objectives/requirements. I see the following
advantages with such a strategy:
1) standards compliant. Applications relying on entity beans to encapsulate
shared, server resident data will execute correctly on any EJB server
(regardless whether the server does the "optimization" in question or not).
2) pass-by-reference semantics is used. Hence collateral, server resident
data can be efficiently shared and reused with automatically provided access
synchronization.
3) transaction semantics on shared data is standard. There is no need to
step out of the EJB programming paradigm to share server resident data
(which is the case when proprietary OODB technologies are used).
4) standard and scalable caching of shared data is straightforward to
implement (possibly to local files). Again, there is no need to leave the
EJB paradigm to implement an effective caching solution.
Furthermore, servers should optimize calls when immutable non-remote Java
objects are passed (e.g. Strings, Integers etc.). As a generalization of
this, I believe it would be beneficial to include a standard "Immutable"
interface into the EJB spec. A developer could mark non-remote, plain Java
objects with this interface to provide hints for safe pass-by-reference
optimizations in a portable fashion.
Imre Kifor
Valto Systems
-----Original Message-----
From: Jim Frentress <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, June 10, 1999 2:43 PM
Subject: Re: Intra-vm pass-by-reference optimization (again)
>the speed can be very well worth it. your concerns are valid enough and the
>ejb1.1 spec is clear enough on the topic by requiring that RMI by-value
>semantics are to be followed by a compliant server. the vendor in question
>has announced that they are enhancing their implementation to follow
>by-value semantics by default while allowing current customers like myself
>to use by-ref if they choose to.
>
>> -----Original Message-----
>> From: Chip Wilson [SMTP:[EMAIL PROTECTED]]
>> Sent: Thursday, June 10, 1999 10:24 AM
>> To: [EMAIL PROTECTED]
>> Subject: Intra-vm pass-by-reference optimization (again)
>>
>> Hello all,
>>
>> I am deploying an EJB application in multiple application servers. For
>> the
>> most part, portability has been very good to excellent, compared to the
>> alternative technologies. I have encountered one huge problem, however.
>>
>> 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
>> pass-by-value
>> to pass-by-reference. This quite predictably causes all kinds of
problems
>> as parts of the application that were never intended to share state end
up
>> walking all over each other's objects.
>>
>> I know that this is implicitly prohibited by the 1.0 spec, and explicitly
>> prohibited in the 1.1 spec. I know that the argument has been made here
>> and
>> elsewhere that the performance improvement is "worth it".
>>
>> I also know that to an application developer, whether a method has
>> pass-by-value semantics or pass-by-reference semantics is very important.
>> So important that other languages (besides Java) which support both sets
>> of
>> semantics require the method declaration to indicate for each parameter
>> and
>> the return value which semantics apply. Saying that a particular method
>> sometimes has one set of semantics and sometimes the other, and there is
>> no
>> way for the calling code to know which semantics apply on a given
>> invocation, causes predictable guffaws from the rank and file.
>>
>> My questions:
>> * How wide-spread is this "optimization"?
>> * Do vendors have plans to deprecate this practice, or will it be
>> carried forward?
>> * Will there be a certification program to determine and publicize
>> which servers are actually spec compliant?
>>
>> 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".
>
>===========================================================================
>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".
