-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

IIRC, in this thread I mentioned that Options is per invocation. So if
user wants to do multiple invocation with the same Options object then
he needs to clone or copy it to another object.

So as you have illustrated, you CAN NOT use the same options within that
that loop. What we can do is provide a clone method and let the user
copy it to a new Options object.

Ok, there are two cases.

1. User creates and Options object and do an invocation. In that case we
do not need to copy all the properties in to the message context as we
are using the same Options object.

2. User creates loops, access the same method several times, same
handler deployed in several places and tries to use the same Options.

IMO, first case is very much used than the second case. I prefer to give
priority to the base case than to the complex case, if the complex case
also works with that method. So if the same Options object is used
within the engine also then it is simpler even within the engine code.


Glen Daniels wrote:
> 
> A little code:
> 
> public class MyTestProgram {
>   public static void main() throws Exception {
>     Options opts = new Options();
>     // ...initialize options...
>     while (a_very_long_time) {
>       ServiceClient client = new ServiceClient(opts);
>       // ... do some more stuff ...
>       client.sendReceive(...);
>     }
>   }
> }
> 
> So every time around that loop, that Options object is becoming not only
> the storage for the stuff that the user put there, but also for any
> properties that the Handlers which run happen to put there.  Let's say
> you've got a Handler that can be deployed multiple times on a given
> flow; one that performs some function and then counts the number of
> times it has been invoked in a given message flow.  So it has code like:
> 
>   Integer count = (Integer)msgContext.getProperty("myCount");
>   if (count == null) count = new Integer(0);
>   count = new Integer(count.intValue() + 1);
>   msgContext.setProperty("myCount");
> 
> Now, the idea is to record the number of invocations per MESSAGE, which
> is why it's writing to the *Message*Context.  You can see how the second
> time around the loop, the count becomes incorrect, right?  Because the
> property isn't per-MessageContext, it's per-Options.  Bad.

well, this happens only if the user uses the *same* Options object for
multiple invocations, which is wrong. That is why I mentioned in one of
my earlier emails also that Options object is per invocation.

If you want to do multiple invocations, clone the options object. I am
sorry I can not see a problem in that.

> 
> That's one kind of problem.  Another is that Handlers might use largish
> data structures and put them in MessageContext properties - any such
> structures won't get GC'ed for as long as the Options object is held...
> and that might be a long time (for instance I can imagine an Axis2
> system running in a continuous loop polling shop floor equipment
> checking for alert conditions - too hot, low on oil, etc).

Why do you think Options object will be there. After an invocation user
dumps it and uses another options object.

So this is the summary of what I am trying to say.
- - Options object (eventhough the name is bit weird. Dr. Sanjiva can you
remember we discussed that the name is not appropriate to that object?)
is per invocation only.
- - if you want to do multiple invocations, you need to either create a
new Options object or clone the previous one.

In this approach, there is no un-necessary copying of properties or
within the execution path.

Glen, I apologize if I still not got the point that you are trying to
make here. That may be why I am still thinking current impl is correct.

Chinthaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGgdLtjON2uBzUhh8RArZRAJ4pGt2VWMRGwHekjN/ATNZ246VIagCeIFU/
+LHUDco0L/KNlWt3E+K/oSI=
=KG3D
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to