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
