hey hey, let's take it online new site is up with NUKES and it rocks, 

you can see who is on and stuff

marcf

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of julien viet
> Sent: Thursday, March 27, 2003 10:11 AM
> To: Bill Burke
> Subject: Re[2]: [JBoss-dev] AOP versioned ACID objects 1st iteration
> 
> 
> 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 
> BB> POJO through the proxy.  I am going to write a 
> constructor-pointcut 
> BB> that will always return a proxy instead of the real POJO on 
> BB> 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, 
> BB> a full snapshot is taken of the real object.  All access to the 
> BB> object is done 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 
> BB> problem being, how do you determine when a POJO's state 
> has changed?  
> BB> For instance:
> 
> BB> Pojo.someHashMapField.get().setValue(blah).  You see my point?
> 
> BB> A full deep copy greatly simplifies the code.  Simplicity == 
> BB> robustness. Plus I'm not even sure versioned fields would 
> be better 
> BB> performing.  Field interception is quite expensive and versioned 
> BB> fields would need field interception.
> 
> BB> The code is under:  
> BB> 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
> 



-------------------------------------------------------
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