Every SDO parameter ultimately boils down to one of the basic types (int, bool, char, etc) and SDO manages the memory for those basic types internally. So if you do a DataObjectPtr::setBoolean( xpath, bool ), you'll be passing in the value with "pass by value" semantics, but the SDO takes care of copying the value and managing the memory for the bool.
I don't think the memory will be an issue if we use SDO here instead of the Operation class. It seems odd to me to have to allocate the basic types with new and pass in the pointer to the Operation class setters. Besides the fact that I don't think those new'ed parameter values ever get deleted (big memory leak). Once the SDO RefCountingPointer detects that no one else is using the SDO, it will take care of releasing the memory itself. As for the return values: That will be an SDO as well. The Service implementation will make the appropriate set calls on the return SDO, which the Tuscany runtime will be able to query. And again, when the no one else is referencing the SDO, the memory will be released. -------------------- Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -----Original Message----- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 2:50 PM To: [email protected] Subject: Re: [SCA Native] Does the Operation class duplicate the SDO I would imagine we can map the contents of the Operation into an SDO. Would this cope with "pass by reference" semantics? Would we be storing copies of the parameters in the SDO or pointers to them as is the case now with the Operation class? If so do we still get the same memory management problems as today? It seems a long time ago since we came up with the Operation class. I recall the interesting problems were around parameters and return values that are pointers or references ... and who allocates/frees the memory. Can we optimise this for local calls (pass by reference) or do we always pass by value? This area certainly needs a fresh brain to look at it ;-) Cheers, On 27/09/2007, Brady Johnson <[EMAIL PROTECTED]> wrote: > > I've been looking at how the Operation class works and have been > considering refactoring it since it has some memory leaks and should > use STL templates, and I came to the realization that its duplicating > a lot of what SDO does. The Operation class seems to serve 2 purposes: > - Store the Operation Name > - Store the Operation Parameters > > All of the Operation setReturnValue(), addParameter(), and > getParameter() methods are duplicating what an SDO DataObject does, so > why not just use an SDO? The method signatures that use the Operation > class can be changed to take a std::string for the operationName and > to take a DataObjectPtr for the parameters. The DataObjectPtr can > contain a DataObjectPtr child for each WSDL message part. > Additionally, I suggest adding a 3rd argument, which would be the > output message, so the resulting ServiceWrapper::invoke() signature would look like this: > > void ServiceWrapper::invoke( const std::string &operationName, > DataObjectPtr input, DataObjectPtr output ); > > If we take this approach, the affected areas will be the samples > (anywhere a ServiceWrapper is used) and scagen. > > Any opinions? > > -------------------- > Brady Johnson > Lead Software Developer - HydraSCA > Rogue Wave Software - [EMAIL PROTECTED] > > -- Pete --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
