Digging throught that thread and the bela discussion of cache.

> There is only one proxy, but you are correct.  For each
> transaction, a full snapshot is taken of the real object.  
> All access to the object is done through one proxy.

The point being made was that there is another way to do this that I find a
little more intuitive (and it seems to solve the Person.getAddress()
instrumentation problem of bela, done). 

Essentially instrument the get/set methods (eventually field in V2 if we can
do it right) and then you are instrumenting the actual instance.   The
reference you are holding to an object, even if dynamically instrumented
(such as an object inserted in cache) is held, get/set do not require that
you get a new reference. 

Sacha pointed out to me in Paris that using a proxy may be a simpler way for
you to deal with the Remoteness aspect, which does always require this
proxy, I doesn't' help on the server though. 

> The performance hit is the full deep copy not the
> synchronization. Synchronization is only:
> 
> realObject = snapshot;
> 
> Remember, we're optimistically locking here.  (Although I'd
> like to optionally provide a transactional lock in the near future).

Ok.  Serialization is needed because you are just doing deep copy of the
object (simple I agree).  But in fact we do have the knowledge of state
changes for most basic types/all application types as we make a requirement.
That means that tracking the individual field changes as in CMP2.0 is a
given.  All individual sets should trigger versioning of the individual
fields.  As we realized in the cache discussion with Bela and you this
essentially does away with the serializable requirement.

> The alternative solution is much much more complex.  The
> biggest problem being, how do you determine when a POJO's 
> state has changed?  For instance:
> 
> Pojo.someHashMapField.get().setValue(blah).  You see my point?

For most types it is trivial but for Maps.  Adrian has a very simple
solution to this, pitched it in Paris.  In fact he didn't even men.  Simply
overwrite the class in the class pool so that when a CL asks for HashMap()
you really return a JBossHashMap which has the CRUD operations overloaded
(something like that I wasn't really fully there that night, mostly drunk). 

Simple. 

For most POJOS it is trivial.

Meaning that 

pojo.setSomeField(value); 

is an instrumented method with either

/*
* jboss-tag:acid=true
* 
* when david gets around to writing XDoclet in AOP :)
*
*/
public class stuffWeWantACID

which generates the XML description of it
<aspects>
<class name="ACID.Pojo">
<interceptor name="doTheAcidVersioning" pointcut="get*,set*"> 
</class>

We can then trivially acidify the state of that object as originally
imagined and prototyped by Julien at NIST.  Pure bytecode instrumentation of
the actual reference. 

As far as references in the POJO, we also talked about the fact that we
solve the problem by simply recursing through the ACID reference so that a
tree of state, when reaching leaves is trivially serializable and thus
achieving fined grained acidity of the tree state. 

> better performing.  Field interception is quite expensive and
> versioned fields would need field interception.

get/set requirement would trivially solve the problem in first iteration,
field in second.  As we know it is the same class of problem we see in ACID,
Cache and persistence. Simply that we need to instrument get/set on the
code.


marcf

<<attachment: winmail.dat>>

Reply via email to