commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: [AltRMI] New Direct-Marshalled transport type
Date Sun, 27 Jan 2002 11:21:30 GMT
Juozas,

> <skip>
>
>>> But I don't know how  to handle  "By Value".
>>> void myMethod( MyInterfaceType mt ){
>>>     mt.setSomething("X");//Don't understand how to handle this (  is 
>>> X set on copy of Object  ? )
>>>    }
>>
>>
>> X will be a copy of the object if pass by value or over the wire.  
>> I'm not quite sure what your asking here.
>
>
> Yes, communication is my problem :(
> I try to see framework or API as user .
> I see two problems in "transparence". Distributed and Persistent 
> objects have problem with
> "Fatal Errors" like "Connection is lost" and "By Value" then users 
> code tries to set something on copy of object.
> Transparent objects doe's not implement any "Tag Interface" and doe's 
> not throw checked Exceptions
> specific for way they are marshaled.
> ////////////////////////////////////////////////////////////////////////// 
>
> Problem 1 :
> users code ("Fatal Errors specific for framework implementation" )
>
>  void myMethodUsesTransparentObject(  Transparent transparent ){
>       try{
>         transaction.begin();
>         transparent.doSometing();//throws some App Exception
>         transparent.setSomething();
>         .........................................
>         transaction.commit();
>
>     }catch(SomeCheckedAppException sce){
>           log(sce);
>       transaction.rollback();
>     }
>     // I forgot to handle "Connection is lost " and compiler says 
> nothing.
>     // My transaction is incomplete and it is very possible I have a 
> "Lock" forever on some resource.
>    // It can be impossible to find this bug for user. We need 
> solution, I don't have it.

For the connection failures issue, the client-side user is informed via 
a AltrmiInvocationException.  This can be caught in a number of places. 
 My preference would be in a single nexus :

void initialize() {
  try {
   // method calls
  }catch ( AltrmiInvocationException ae ) {
    if (transaction != null) { transaction.rolback(); }
    getLogger().error("blah",ae);
    throw ae; // or a new one.
  }catch (Throwable) {
    // something similar.
  } 
}

Of course with a bean container a "policy" can be set for a bean, so 
that predictable actions take place.

>  }
>
> ////////////////////////////////////////////////////////////////////////// 
>
>
> Problem 2 :
>
> User calls my transparent objects he don't know marshaling stuff, 
> implements "callbacks" sets "Context" ... .
> He knows :
> virtual void my_cpp_method( transparent object )=0;// "By Value"
> irtual void my_cpp_method1( transparent & object )=0;// "By Reference"
> procedure MyPascalProcedure(  var  aObject : TTransparent  ) virtual 
> abstract; (* "Always By Reference " *)
> public void myJAVAMethod(Transparent transparent);// sometimes "By 
> value" ? Transparent has no "Tag" interface
> User knows usual stuff, and "Transparence" must become usual. 

In this case, the class containing the method myJAVAMethod() is a facade 
and proxyed to an equivalent on the server.  You are worried about 
"Transparent" class and how AltRMI knows whether it is pas by value or 
by reference (a facade).  Easy,  at time of publication, the developer 
designates a number of additional interfaces as facades rather than pass 
by value.  If it is known that Transparent has setter functions that 
could cause problems make it an addition facade.  There is no need for a 
Tag (Marker?) interface.  The downside is that Transparent.class needs 
to be an interface with one or more impls.  But then that is the same 
rule taht RMI has for solving the same issue.

> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

>
>
> Very possible to train users, write books, documentation, I don't know 
> is it solution or not.
> I have no solution for this two problems.
> It is because I trying to think as user, I must think about my team it 
> is my job.
> I like transparence, but I think it can kill users project if will not 
> solve my problems. 

I hope I have addressed your concerns Juazos.  I think you know yourself 
that you're little hard to understand.  Sadly so I am, but I don't have 
the excuse of having English as a first language ;-)

Regards,

- Paul


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message