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
