when I thought about this, I was trying avoir the current construct :

B oldB = a.getB();
C oldC = a.getC();
try
{
   a.setB(b);
   a.setC(c);
}
catch(Throwable t)
{
   a.setB(oldB);
   a.setC(oldc);
}

and I was trying to find a way to make atomic Deployment within
deployers. Deploy all or nothing.

Bill, with AOP fwk would that be possible to know how many bytes
an object takes effectively ?

((ObjectStat) pojo).getBytesInMem();

Instrument the pojo to iterates over its fields and computes
its memory footprint.

julien

>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] Behalf Of
>> Karthik
>> Sent: Thursday, March 27, 2003 1:25 AM
>> To: [EMAIL PROTECTED]
>> Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
>>
>>
>> Hi bill,
>>    The versioning of POJO is very good. I have some issues here. If I
>> version a object, then I have to maintain all the state in the same POJO

BB> How is this not the general case?  All application code accesses the POJO
BB> through the proxy.  I am going to write a constructor-pointcut that will
BB> always return a proxy instead of the real POJO on construction.

>> which is not the general case and will bloat the code. The states are
>> maintained in the helper classes. Also defining each POJO as versioned is
>> meaningless. If new proxies are created for each transaction with the deep
>> copy of all the state or maintain a pool and synchronize the state after
>> update,  it will become real performance bottleneck.How do you tackle this
>> problem?

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

BB> The performance hit is the full deep copy not the synchronization.
BB> Synchronization is only:

BB> realObject = snapshot;

BB> Remember, we're optimistically locking here.  (Although I'd like to
BB> optionally provide a transactional lock in the near future).

BB> The alternative solution is much much more complex.  The biggest problem
BB> being, how do you determine when a POJO's state has changed?  For instance:

BB> Pojo.someHashMapField.get().setValue(blah).  You see my point?

BB> A full deep copy greatly simplifies the code.  Simplicity == robustness.
BB> Plus I'm not even sure versioned fields would be better performing.  Field
BB> interception is quite expensive and versioned fields would need field
BB> interception.

BB> The code is under:  varia/src/main/org/jboss/aop/plugins/Version*.java
BB> testcase is under testsuite/src/main/org/jboss/test/aop/bean/Version*.java
BB> (take a look at the AOP DD under
BB> testsuite/src/resource/aop/META-INF/jboss-aop.xml too).

BB> Bill



>>    Correct me if I am missing something.
>>
>>    Where or when can get the code from the CVS?
>>
>> Thanks
>>
>> Karthi
>>
>> > -----Original Message-----
>> > From: [EMAIL PROTECTED]
>> > [mailto:[EMAIL PROTECTED]
>> > Behalf Of Bill
>> > Burke
>> > Sent: Thursday, March 27, 2003 10:43 AM
>> > To: [EMAIL PROTECTED]
>> > Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
>> >
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: [EMAIL PROTECTED]
>> > > [mailto:[EMAIL PROTECTED]
>> > Behalf Of Jeff
>> > > Haynie
>> > > Sent: Wednesday, March 26, 2003 11:51 PM
>> > > To: [EMAIL PROTECTED]
>> > > Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
>> > >
>> > >
>> > >
>> > > >JBoss Remoting is much more fabulous.  We need to get the
>> > word out on
>> > > it...
>> > >
>> > > I need to write some darn docs.. Too busy trying to get a
>> > new release
>> > > out on our side. Not enough hours in a day.
>> > >
>> > >
>> > > > I totally agree.  And yes, a constructor pointcut is the
>> > way to go.
>> > > The only downside of constructor pointcuts is that
>> > reflection bypasses
>> > > the interception!
>> > > > Same thing with field interception.  The problem is that unlike
>> > > methods, you have to modify the bytecode of the calling logic.
>> > >
>> > > Could you dynamically do an insertBefore into the
>> > CtConstructor of the
>> > > advised class which would do the interception, even on reflection?
>> > >
>> >
>> > I'm not sure...The problem with Versioning and Remoting is
>> > that a proxy
>> > object is required.  You have to return a different object
>> > than the one
>> > actually constructed.  You getting me?  I'm not sure if this
>> > can be done
>> > within bytecode manipulation.  I'll have to ask the Javassist guys.
>> >
>> > > > I will write some testcases that put the whole stack together with
>> > > constructor pointcuts.
>> > > >
>> > > > I'm also working on the concept of an abstract Container.
>> >  But you got
>> > > me thinking that constructor pointcuts may be enough...
>> > >
>> > > I was just going to email you about the Container - just
>> > looking through
>> > > the code. Is this just the ability to create an AOP namespace or
>> > > something?
>> > >
>> >
>> > I guess you could think of it in that way and use it in that
>> > way, but the
>> > original intent was to handle things like dynamic loading through the
>> > persistence mechanism much in the same way an Entity Bean
>> > Container handles
>> > invocations on objects that are not in memory yet.  You get
>> > what I'm saying?
>> >
>> > Bill
>> >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > -------------------------------------------------------
>> > > This SF.net email is sponsored by:
>> > > The Definitive IT and Networking Event. Be There!
>> > > NetWorld+Interop Las Vegas 2003 -- Register today!
>> > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
>> > > _______________________________________________
>> > > Jboss-development mailing list
>> > > [EMAIL PROTECTED]
>> > > https://lists.sourceforge.net/lists/listinfo/jboss-development
>> >
>> >
>> >
>> > -------------------------------------------------------
>> > This SF.net email is sponsored by:
>> > The Definitive IT and Networking Event. Be There!
>> > NetWorld+Interop Las Vegas 2003 -- Register today!
>> > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
>> > _______________________________________________
>> > Jboss-development mailing list
>> > [EMAIL PROTECTED]
>> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by:
>> The Definitive IT and Networking Event. Be There!
>> NetWorld+Interop Las Vegas 2003 -- Register today!
>> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
>> _______________________________________________
>> Jboss-development mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/jboss-development



BB> -------------------------------------------------------
BB> This SF.net email is sponsored by:
BB> The Definitive IT and Networking Event. Be There!
BB> NetWorld+Interop Las Vegas 2003 -- Register today!
BB> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
BB> _______________________________________________
BB> Jboss-development mailing list
BB> [EMAIL PROTECTED]
BB> https://lists.sourceforge.net/lists/listinfo/jboss-development



-- 
Best regards,
 julien                            mailto:[EMAIL PROTECTED]



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to