In the "Cocobase Questions" forum (thread "Transactions and user-defined generic proxies"), I was told that the only proxy class supported by the Transaction object was CocoProxyM and that I should derive my proxies from that object if I wanted transaction support. That works but I like to suggest defining a proxy interface. There are several reasons for this suggestion. CocoProxyM is a concrete object and I may not need or want all of it's functionality in my application-specific proxy class. Also, my understanding is that the "M" in the name signifies that it is a method-based proxy (vs. the CocoProxy which is field based). I have defined a custom field-based proxy, yet I have to inherit from CocoProxyM. This seems a bit strange. If a proxy interface were defined and then implemented by both CocoProxy and CocoProxyM, they both could be supported by the transaction code. Furthermore, it would provide end users with a cleaner mechanism for defining custom proxies with full transaction support.

Actually we don't need a Proxy Interface, that's what the
CBProp inteface is. The issue is that we haven't modified
the Transaction object to allow you to override the proxy
with an additional version of a class that implements that
interface. We will allow that extension eventually, it just
hasn't been a high enough priority since we ship the class
CocoProxyM as source code to customers for their extensions
to be added. You can find the source code in the demos\pguide
subdirectory of the product.

Hope that helps clarify this!

THOUGHT Support

CBProp doesn't satisfy all the requirements of a Proxy for Transaction purposes. If it did, then CocoProxy could also be used with Transactions since it implements CBProp. Specifically, you need additional semantics for a Proxy interface. For example, accessors for the proxy's delegate object (e.g. setObject/getObject) so that the Transaction can copy the delegate's state when an object is bound to a Transaction. The Proxy interface should also derive from Cloneable or an equivalent so the proxy object's state can be copied along with the delegate's state. As an example, during our evaluation we have created a high performance proxy that doesn't look up data field and method objects on every setPropObjectData. To support this approach, we needed to store the map name in the proxy. The problem is that the map name is not copied with the proxy during a Transaction bind. To workaround the problem we had to derive from CocoProxyM and use the setKeyValue/getKeyValue methods of that class to pass the map name. A little strange, to say the least, but it worked. We're keeping our fingers crossed that we don't need the set/getKeyValue methods for their intended purpose. A proxy interface with delegate access and cloning ability would be a much better solution.

Ok there are several things we need to respond to in this
email.

1) We'll be producing a solution for using multiple Proxy
objects, but you can just as easily incorporate your
enhancements into the CocoProxyM class without requiring a
separate Proxy interface.

2) The Transaction object does copy the 'state' of the object
if CocoProxyM is used so if you follow step 1 this will happen.

3) The Transaction should be bound using the map name if you
are using a CocoProxyM so instead of

cocoTxn.bind(proxyInstance);
instead use:
cocoTxn.bind(proxyInstance, mapName);

4) CocoProxyM already implements cloneable.

Hope this helps explain this better.

THOUGHT Support