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