> If you use versioning on a POJO that is a the top of > an object graph, will the children objects also be > versions when they are modified??? > > I assume No. But I think it would make sense for your
correct. > Versioning interceptor to wrap up children objets with the > versioning proxy also when they are accessed. > That way if you do a: not needed on reference work, just recursively instrument all get/set of the objects in the graph. As a reference of the top node, if we declare the top one to be advised, we can in fact dynamically instrument the references for the same acidity, when they are assigned to the class and that recursively. > > pojo = (POJO)Versioned.makeVersioned(pojo); > pojo.getAccount().getBalance().add(10.00); > > The modification of the Balance object will be > versioned too. Does that make sense to you?? Do you > do this now?? > we can as described in my previous mail. getBalance() is a method that does a setBalance(getBalance+10.00); and we detect that one change and that one change only. marcf > Regards, > Hiram > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > > > -----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 > > > > How is this not the general case? All application > > code accesses the POJO > > through the proxy. I am going to write a constructor-pointcut that > > will 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? > > > > 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 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). > > > > 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? > > > > A full deep copy greatly simplifies the code. > > Simplicity == robustness. > > Plus I'm not even sure versioned fields would be > > better performing. Field > > interception is quite expensive and versioned fields > > would need field > > interception. > > > > The code is under: > > varia/src/main/org/jboss/aop/plugins/Version*.java > > testcase is under > > > testsuite/src/main/org/jboss/test/aop/bean/Version*.java > > (take a look at the AOP DD under > > testsuite/src/resource/aop/META-INF/jboss-aop.xml > > too). > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > === message truncated === > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your > desktop! http://platinum.yahoo.com > > > ------------------------------------------------------- > 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 >
<<attachment: winmail.dat>>
