RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
1) POJO pojo = new POJO(); pojo = (POJO)Versioned.makeVersioned(pojo); That is really pretty tho :) You need to define the pojo as aspectable (advisable). or 2) Define a constructor-pointcut on the POJO class (I will implement this today.) nice, marcf Agreed. A remote proxy must figure out at marshall time how it can comunicate back to the server. but, but but... so we are in the AOP remote and we are about to return an object to the remote caller. Can the response do return AOPRemote.makeRemote(object); ? So that even the proxy is constructed as needed (meaning when you return?) marcf 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 attachment: winmail.dat
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Digging throught that thread and the bela discussion of cache. 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 point being made was that there is another way to do this that I find a little more intuitive (and it seems to solve the Person.getAddress() instrumentation problem of bela, done). Essentially instrument the get/set methods (eventually field in V2 if we can do it right) and then you are instrumenting the actual instance. The reference you are holding to an object, even if dynamically instrumented (such as an object inserted in cache) is held, get/set do not require that you get a new reference. Sacha pointed out to me in Paris that using a proxy may be a simpler way for you to deal with the Remoteness aspect, which does always require this proxy, I doesn't' help on the server though. 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). Ok. Serialization is needed because you are just doing deep copy of the object (simple I agree). But in fact we do have the knowledge of state changes for most basic types/all application types as we make a requirement. That means that tracking the individual field changes as in CMP2.0 is a given. All individual sets should trigger versioning of the individual fields. As we realized in the cache discussion with Bela and you this essentially does away with the serializable requirement. 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? For most types it is trivial but for Maps. Adrian has a very simple solution to this, pitched it in Paris. In fact he didn't even men. Simply overwrite the class in the class pool so that when a CL asks for HashMap() you really return a JBossHashMap which has the CRUD operations overloaded (something like that I wasn't really fully there that night, mostly drunk). Simple. For most POJOS it is trivial. Meaning that pojo.setSomeField(value); is an instrumented method with either /* * jboss-tag:acid=true * * when david gets around to writing XDoclet in AOP :) * */ public class stuffWeWantACID which generates the XML description of it aspects class name=ACID.Pojo interceptor name=doTheAcidVersioning pointcut=get*,set* /class We can then trivially acidify the state of that object as originally imagined and prototyped by Julien at NIST. Pure bytecode instrumentation of the actual reference. As far as references in the POJO, we also talked about the fact that we solve the problem by simply recursing through the ACID reference so that a tree of state, when reaching leaves is trivially serializable and thus achieving fined grained acidity of the tree state. better performing. Field interception is quite expensive and versioned fields would need field interception. get/set requirement would trivially solve the problem in first iteration, field in second. As we know it is the same class of problem we see in ACID, Cache and persistence. Simply that we need to instrument get/set on the code. marcf attachment: winmail.dat
Why the forums suck (Was: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration)
On Thursday, Mar 27, 2003, at 18:25 Europe/Amsterdam, Bill Burke wrote: We've been trying hard to keep the development forums as the base of design discussions. There's a lot of good information there. The information there is good, but it is a pain to access the forums. Here are some of the reasons: The jboss site is bloated with content. If i'm there to read forums I don't want to see flashing banners all the time. It slows down page loading a lot and takes up a lot of space on the screen. The development forums are marked with 'no user questions here please' but nobody seems to care much. Questions about *any* subject are posted in random forums. Searching in the forums is a pain. It would be so much nicer to be able to search by subject, and not see every single article in a thread but just the unqiue thread names. It is *slow* to read. Nothing beats a good news or email reader. I read/browse through a backlog of 100 messages on this list in 15 minutes. On the forums it will take hours to even find the last messages. What would really help is a forum2email gateway to relay new messages to an email address. I know that begging for features is not allowed here :) so if it an option to add that as a module to the new nukes stuff then I can help out with that. S. --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Why the forums suck (Was: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration)
\ What would really help is a forum2email gateway to relay new messages to an email address. I know that begging for features is not allowed here :) so if it an option to add that as a module to the new nukes stuff then I can help out with that. OK :) marcf S. --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020 aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Again, you have the problem of primitive types. These would require field interception which is slow. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bela Ban Sent: Monday, March 31, 2003 7:11 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration Hiram Chirino wrote: That might be a problem if you have a big object graph. You get a big penalty even if you only modify a small peice of the object graph. You could do a shallow copy by getting a snapshot of the fields of the object. Then wrap up the children objects with Versioned.makeVersioned(child) when they are accessed. The cool thing is that you would not have any serialization at all. I know that there has to be some down-sides to this approach, help me figure them out. This essentially requires recursively wrapping all child objects reachable from a parent with version interceptors. I think this is what I would require for my cache, which is tree-structured. Versions would be created only when needed, as we go. -- Bela Ban www.javagroups.com (408) 316-4459 --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Dave Smith: May God Bless America and Java. That is a very humanistic thing that you wish here, but you make a small typo. As a friend of Java you know that Java is in Indonesia and Indonesia is the country with the most Muslims all over the word. So you should better write God Bless America and Ala take care of Java. Or better, based on OO more abstract : A higher power should take care on each human. May the bit's bust the internet to bring more education to this world. Stefan --- 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
IMPRESSIVE BILL! Congratulations! Not only does this is impressive, but it is ridiculously EASY to use. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: jeudi, 27. mars 2003 01:09 To: Jboss-Dev Subject: [JBoss-dev] AOP versioned ACID objects 1st iteration I have implemented a new AOP service for Serializable POJOs, Versioned Objects. You can transactionally version an object. If you modify the object within a transaction, this modification is not seen by other transactions. If the tx commits, the changes seen, if a rollback happens the changes are rolled back. On commit, if another tx has modified the object, the tx will rollback (OptimisticLocking). The way it works is as follows: POJO pojo = new POJO(); pojo = (POJO)org.jboss.aop.plugins.Versioned.makeVersioned(pojo); calling Versioned.makeVersioned creates a proxy that sits in front of the real object. transactionManager.begin(); pojo.callMethod(); when callMethod is invoked since there is a transaction, an interceptor creates a copy of the REAL pojo and does all further invocations on this copy. pojo.someField = 5; If you have field interception turned on, public field will also be accessed via the copy/version tm.commit(); On commit, a tx Synchronization checks to see if the version you have created is the latest and greatest. If not an org.jboss.aop.plugins.OptimisticLockFailure exception is thrown in beforeCompletion. I'm not sure how this exception is wrapped. Some other semantics: 1. All method invocations force a version to be created. You can avoid this by declared class-metadata as follows: class-metadata name=234234 group=VERSIONED class=org.jboss.test.aop.bean.VersionedPOJO method name=get.* read-onlytrue/read-only /method /class-metadata A readonly method will not cause the creation of a version and the current object will be used. An example and unit test is under testsuite/src/main/org/jboss/test/aop/bean/VersionedObjectTester.java The example object VersionedPOJO.java, has 1 interceptor pointcut declared on the class to do Tx stuff. See testsuite/src/resources/aop/META-INF/jboss-aop.xml for more details. What would be nice is to also write a TransactionalLock interceptor for versioned POJO's that have high OptimisticLock failures. 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
-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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Karthik Sent: Thursday, March 27, 2003 1:35 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration Versioning -- Versioning can be done by Byte code manipulation. Instead of maintaining the state as a proxy, you can maintain the state in a list in the manipulated class. That's just silly. If the state is maintained globally within the class, you would have to protect this state within a synchronized block and you would have high high global contention and low performance. Besides, the proxy I generate should replace the real object and all access to the object is done through the proxy instance. Either: 1) POJO pojo = new POJO(); pojo = (POJO)Versioned.makeVersioned(pojo); or 2) Define a constructor-pointcut on the POJO class (I will implement this today.) Remoting -- has to be done through proxy, but abstract the user by the Inteceptor sending the proxy based on the communication layer. Agreed. A remote proxy must figure out at marshall time how it can comunicate back to the server. 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Bill, 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 Versioning interceptor to wrap up children objets with the versioning proxy also when they are accessed. That way if you do a: 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?? 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
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. Why? Basically in rmeoting, you would just dispatch each method invocation across the wire and the local object would just serve as a phantom object and not actually contain any state, etc. Why does it has to be a real proxy...? Maybe I'm not following. That way, I could new an object, which is actually a local representation of a remoted object on another machine. I could also add a clustered intercetor which might then load balance invocations across to different real remote objects. I think this is possible. Right? Another thing to think about ... After looking at the javassist docs last night is something like using casting to dynamically add interceptors. This might be bad, haven't thought through all the implications ... But, imagine: Foo foo = new Foo (); // local object ((Transactable)foo).beginTx(); Foo.bar(); ((Transactable)foo).commitTx(); What if the mere casting of an object would allow you to dynamically attach an interceptor to the object before the invocation? This might be fairly powerful too. Looking at the javassist docs, it looks like you can get called on a Cast and InstanceOf call to an object. Maybe I'm being too whacky here ... Not sure. Something to ponder. Jeff --- 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Yes, its a deep copy which is why I require Serializable. new MarshalledObject(obj).get(); Maybe there is a better way to make copies? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Thursday, March 27, 2003 10:15 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration Bill, 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 Versioning interceptor to wrap up children objets with the versioning proxy also when they are accessed. That way if you do a: 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?? 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
Re: [JBoss-dev] AOP versioned ACID objects 1st iteration
On Thursday, Mar 27, 2003, at 03:28 Europe/Amsterdam, marc fleury wrote: So in the quest to impove J2EE have you killed it? bla bla bla bla marc fleury wrote: do you motherfuckers realize how BIG this is? obviously some of you don't get it, give it time, it will become very obvious It would be nice if discussions about JBoss 4.0 architecture would move from your internal mailing list to the public -dev mailing list. Maybe then we can get it and also give useful input. JBoss 4.0 is like a black box now. Show us what you are doing. Kudos for Bill of course for sharing, but more info would be nice. Peace. Stefan --- 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
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. Here I mean to say if only deep copy is not made. The performance hit is the full deep copy not the synchronization. Synchronization is only: realObject = snapshot; My thought of pooling is absolute bull shit . One Tx ( worst case one invocation) -- One deep copy even for transactional locking (which may be sequential access) is also bottleneck. But currently, its has to be done like that only. Even though field versioning is too complex or unclear, we should have look over that. Karthik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Thursday, March 27, 2003 8:20 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration -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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
We've been trying hard to keep the development forums as the base of design discussions. There's a lot of good information there. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Stefan Arentz Sent: Thursday, March 27, 2003 11:28 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration On Thursday, Mar 27, 2003, at 03:28 Europe/Amsterdam, marc fleury wrote: So in the quest to impove J2EE have you killed it? bla bla bla bla marc fleury wrote: do you motherfuckers realize how BIG this is? obviously some of you don't get it, give it time, it will become very obvious It would be nice if discussions about JBoss 4.0 architecture would move from your internal mailing list to the public -dev mailing list. Maybe then we can get it and also give useful input. JBoss 4.0 is like a black box now. Show us what you are doing. Kudos for Bill of course for sharing, but more info would be nice. Peace. Stefan --- 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
After looking at the javassist docs last night is something like using casting to dynamically add interceptors. This might be bad, haven't thought through all the implications ... But, imagine: Where is it. I cant find any documents regarding casting and I feel that is impossible because the class is loaded. This prevents our basic discussion of preventing user from knowing the point cuts. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Thursday, March 27, 2003 8:41 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration 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. Why? Basically in rmeoting, you would just dispatch each method invocation across the wire and the local object would just serve as a phantom object and not actually contain any state, etc. Why does it has to be a real proxy...? Maybe I'm not following. That way, I could new an object, which is actually a local representation of a remoted object on another machine. I could also add a clustered intercetor which might then load balance invocations across to different real remote objects. I think this is possible. Right? Another thing to think about ... After looking at the javassist docs last night is something like using casting to dynamically add interceptors. This might be bad, haven't thought through all the implications ... But, imagine: Foo foo = new Foo (); // local object ((Transactable)foo).beginTx(); Foo.bar(); ((Transactable)foo).commitTx(); What if the mere casting of an object would allow you to dynamically attach an interceptor to the object before the invocation? This might be fairly powerful too. Looking at the javassist docs, it looks like you can get called on a Cast and InstanceOf call to an object. Maybe I'm being too whacky here ... Not sure. Something to ponder. Jeff --- 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
That might be a problem if you have a big object graph. You get a big penalty even if you only modify a small peice of the object graph. You could do a shallow copy by getting a snapshot of the fields of the object. Then wrap up the children objects with Versioned.makeVersioned(child) when they are accessed. The cool thing is that you would not have any serialization at all. I know that there has to be some down-sides to this approach, help me figure them out. Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Yes, its a deep copy which is why I require Serializable. new MarshalledObject(obj).get(); Maybe there is a better way to make copies? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Thursday, March 27, 2003 10:15 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration Bill, 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 Versioning interceptor to wrap up children objets with the versioning proxy also when they are accessed. That way if you do a: 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?? 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... === message truncated === __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: [JBoss-dev] AOP versioned ACID objects 1st iteration
On Thursday, March 27, 2003, at 09:57 AM, Bill Burke wrote: Yes, its a deep copy which is why I require Serializable. new MarshalledObject(obj).get(); Maybe there is a better way to make copies? Yes. I wrote an object copier service for just this type for situation. In CMP the spec requires us to return copies of CMP-fields and up until now we just ignored that requirement. The object copier is currently broken, but I expect to have it fixed sometime this weekend. I'll send you some sample code later. -dain --- 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Thursday, March 27, 2003 2:31 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration That might be a problem if you have a big object graph. You get a big penalty even if you only modify a small peice of the object graph. You could do a shallow copy by getting a snapshot of the fields of the object. Then wrap up the children objects with Versioned.makeVersioned(child) when they are accessed. The cool thing is that you would not have any serialization at all. I know that there has to be some down-sides to this approach, help me figure them out. Interesting idea, but I don't know if it would be more performant. The problem is primitive types. You can't make these versionable by themselves and field interception is expensive. Another thing, I'm not sure this approach would work with non-static inner classes. 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
I just want to give credit to Julien Viet as well who pitched that idea when he was in ATL, kudos Bill, you are in orbit, the pings in your head, the code in CVS, let them fight, let's move marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Wednesday, March 26, 2003 7:09 PM To: Jboss-Dev Subject: [JBoss-dev] AOP versioned ACID objects 1st iteration I have implemented a new AOP service for Serializable POJOs, Versioned Objects. You can transactionally version an object. If you modify the object within a transaction, this modification is not seen by other transactions. If the tx commits, the changes seen, if a rollback happens the changes are rolled back. On commit, if another tx has modified the object, the tx will rollback (OptimisticLocking). The way it works is as follows: POJO pojo = new POJO(); pojo = (POJO)org.jboss.aop.plugins.Versioned.makeVersioned(pojo); calling Versioned.makeVersioned creates a proxy that sits in front of the real object. transactionManager.begin(); pojo.callMethod(); when callMethod is invoked since there is a transaction, an interceptor creates a copy of the REAL pojo and does all further invocations on this copy. pojo.someField = 5; If you have field interception turned on, public field will also be accessed via the copy/version tm.commit(); On commit, a tx Synchronization checks to see if the version you have created is the latest and greatest. If not an org.jboss.aop.plugins.OptimisticLockFailure exception is thrown in beforeCompletion. I'm not sure how this exception is wrapped. Some other semantics: 1. All method invocations force a version to be created. You can avoid this by declared class-metadata as follows: class-metadata name=234234 group=VERSIONED class=org.jboss.test.aop.bean.VersionedPOJO method name=get.* read-onlytrue/read-only /method /class-metadata A readonly method will not cause the creation of a version and the current object will be used. An example and unit test is under testsuite/src/main/org/jboss/test/aop/bean/VersionedObjectTester.java The example object VersionedPOJO.java, has 1 interceptor pointcut declared on the class to do Tx stuff. See testsuite/src/resources/aop/META-INF/jboss-aop.xml for more details. What would be nice is to also write a TransactionalLock interceptor for versioned POJO's that have high OptimisticLock failures. 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
second revolution, I just can't say how excited I am. We are doing magic, critical mass. Julien goes I got a silly idea.. bill makes it real, there is war.. we are doing RAW stuff, and rarely was I that excited about it all... you ain't seen nothing yet wankers PLgC marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Wednesday, March 26, 2003 7:09 PM To: Jboss-Dev Subject: [JBoss-dev] AOP versioned ACID objects 1st iteration I have implemented a new AOP service for Serializable POJOs, Versioned Objects. You can transactionally version an object. If you modify the object within a transaction, this modification is not seen by other transactions. If the tx commits, the changes seen, if a rollback happens the changes are rolled back. On commit, if another tx has modified the object, the tx will rollback (OptimisticLocking). The way it works is as follows: POJO pojo = new POJO(); pojo = (POJO)org.jboss.aop.plugins.Versioned.makeVersioned(pojo); calling Versioned.makeVersioned creates a proxy that sits in front of the real object. transactionManager.begin(); pojo.callMethod(); when callMethod is invoked since there is a transaction, an interceptor creates a copy of the REAL pojo and does all further invocations on this copy. pojo.someField = 5; If you have field interception turned on, public field will also be accessed via the copy/version tm.commit(); On commit, a tx Synchronization checks to see if the version you have created is the latest and greatest. If not an org.jboss.aop.plugins.OptimisticLockFailure exception is thrown in beforeCompletion. I'm not sure how this exception is wrapped. Some other semantics: 1. All method invocations force a version to be created. You can avoid this by declared class-metadata as follows: class-metadata name=234234 group=VERSIONED class=org.jboss.test.aop.bean.VersionedPOJO method name=get.* read-onlytrue/read-only /method /class-metadata A readonly method will not cause the creation of a version and the current object will be used. An example and unit test is under testsuite/src/main/org/jboss/test/aop/bean/VersionedObjectTester.java The example object VersionedPOJO.java, has 1 interceptor pointcut declared on the class to do Tx stuff. See testsuite/src/resources/aop/META-INF/jboss-aop.xml for more details. What would be nice is to also write a TransactionalLock interceptor for versioned POJO's that have high OptimisticLock failures. 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
Re: [JBoss-dev] AOP versioned ACID objects 1st iteration
Too bad that the whole world is more intretsed whether or not JBOSS will become J2EE certified. I was reading an article about Unintended Consequences that made me think of the current J2EE cerification vs. JBOSS 4.0 with AOP. In 1349 the black plague was spreading around Europe. In castles and universities and town halls across Europe, great minds pondered the cause of the plague. And they came pretty close. The collective academic wisdom was that the source of the Black Plague was fleas. So the word went out from town to town across Europe - to stop the plague - kill the fleas - by killing all the dogs. And immediately the slaughter of all dogs began. But like lots of well-intentioned academic ideas it was somewhat wide of the mark...and had unexpected consequences. The cause was fleas all right, but not dog fleas...it was rat fleas. And in the 1300's what was the most effective way to hold down the rat population? You guessed it - dogs. So by suggesting that townsfolk kill their dogs, the wise authorities had unwittingly allowed the rat population to flourish and thus a new vicious rash of Black Plague began. Before it was over, three years later, nearly 1 out of 3 people in the world had died of the plague. (John Mauldin) So in the quest to impove J2EE have you killed it? marc fleury wrote: do you motherfuckers realize how BIG this is? no? there is close to NOTHING in 20,000 pages of J2EE about this. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Wednesday, March 26, 2003 7:09 PM To: Jboss-Dev Subject: [JBoss-dev] AOP versioned ACID objects 1st iteration I have implemented a new AOP service for Serializable POJOs, Versioned Objects. You can transactionally version an object. If you modify the object within a transaction, this modification is not seen by other transactions. If the tx commits, the changes seen, if a rollback happens the changes are rolled back. On commit, if another tx has modified the object, the tx will rollback (OptimisticLocking). The way it works is as follows: POJO pojo = new POJO(); pojo = (POJO)org.jboss.aop.plugins.Versioned.makeVersioned(pojo); calling Versioned.makeVersioned creates a proxy that sits in front of the real object. transactionManager.begin(); pojo.callMethod(); when callMethod is invoked since there is a transaction, an interceptor creates a copy of the REAL pojo and does all further invocations on this copy. pojo.someField = 5; If you have field interception turned on, public field will also be accessed via the copy/version tm.commit(); On commit, a tx Synchronization checks to see if the version you have created is the latest and greatest. If not an org.jboss.aop.plugins.OptimisticLockFailure exception is thrown in beforeCompletion. I'm not sure how this exception is wrapped. Some other semantics: 1. All method invocations force a version to be created. You can avoid this by declared class-metadata as follows: class-metadata name=234234 group=VERSIONED class=org.jboss.test.aop.bean.VersionedPOJO method name=get.* read-onlytrue/read-only /method /class-metadata A readonly method will not cause the creation of a version and the current object will be used. An example and unit test is under testsuite/src/main/org/jboss/test/aop/bean/VersionedObjectTester.java The example object VersionedPOJO.java, has 1 interceptor pointcut declared on the class to do Tx stuff. See testsuite/src/resources/aop/META-INF/jboss-aop.xml for more details. What would be nice is to also write a TransactionalLock interceptor for versioned POJO's that have high OptimisticLock failures. 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
So in the quest to impove J2EE have you killed it? bla bla bla bla marc fleury wrote: do you motherfuckers realize how BIG this is? obviously some of you don't get it, give it time, it will become very obvious enough wasted time in the U.N. Time for some good ol' action marcf --- 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
The story about the flees was pretty good though, but kind of irrelevant :) marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of marc fleury Sent: Wednesday, March 26, 2003 9:29 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration So in the quest to impove J2EE have you killed it? bla bla bla bla marc fleury wrote: do you motherfuckers realize how BIG this is? obviously some of you don't get it, give it time, it will become very obvious enough wasted time in the U.N. Time for some good ol' action marcf --- 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
Re: [JBoss-dev] AOP versioned ACID objects 1st iteration
:rotfl .. a Frenchman wanting action This is hot shit. Plain and simple. Take the J2EE spec and piss all over it. When you wrote it your mind was small and feeble, we have seen the light. The question is how long before the world realizes it or does J2EE implode and we all are paying homage to Bill and .NET May God Bless America and Java. marc fleury wrote: So in the quest to impove J2EE have you killed it? bla bla bla bla marc fleury wrote: do you motherfuckers realize how BIG this is? obviously some of you don't get it, give it time, it will become very obvious enough wasted time in the U.N. Time for some good ol' action marcf --- 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Dave, Think about this. If we wait for the spec to implement the kind of stuff dot net is doing, J2EE is dead anyhow. At 10K per CPU J2EE is dead as well. We are moving to a commodity based infrastructure, dot net can play so can open source and IBM. Not sure too many others can join the ride. Realize that we are saving Java not destroying it. More people download JBoss than the reference implementation. Ben Sabrin Director of Sales and Business Development JBoss Group, LLC 404-467-8555 x202 - office 404-664-9466 - cell 404-948-1496 - fax [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED] On Behalf Of Dave Smith Sent: Wednesday, March 26, 2003 10:20 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration :rotfl .. a Frenchman wanting action This is hot shit. Plain and simple. Take the J2EE spec and piss all over it. When you wrote it your mind was small and feeble, we have seen the light. The question is how long before the world realizes it or does J2EE implode and we all are paying homage to Bill and .NET May God Bless America and Java. marc fleury wrote: So in the quest to impove J2EE have you killed it? bla bla bla bla marc fleury wrote: do you motherfuckers realize how BIG this is? obviously some of you don't get it, give it time, it will become very obvious enough wasted time in the U.N. Time for some good ol' action marcf --- 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Smith Sent: Wednesday, March 26, 2003 9:17 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration Too bad that the whole world is more intretsed whether or not JBOSS will become J2EE certified. I was reading an article about Unintended Consequences that made me think of the current J2EE cerification vs. JBOSS 4.0 with AOP. In 1349 the black plague was spreading around Europe. In castles and universities and town halls across Europe, great minds pondered the cause of the plague. And they came pretty close. The collective academic wisdom was that the source of the Black Plague was fleas. So the word went out from town to town across Europe - to stop the plague - kill the fleas - by killing all the dogs. And immediately the slaughter of all dogs began. But like lots of well-intentioned academic ideas it was somewhat wide of the mark...and had unexpected consequences. The cause was fleas all right, but not dog fleas...it was rat fleas. And in the 1300's what was the most effective way to hold down the rat population? You guessed it - dogs. So by suggesting that townsfolk kill their dogs, the wise authorities had unwittingly allowed the rat population to flourish and thus a new vicious rash of Black Plague began. Before it was over, three years later, nearly 1 out of 3 people in the world had died of the plague. (John Mauldin) So in the quest to impove J2EE have you killed it? Pope Paul V ordered Bellarmine to have the Sacred Congregation of the Index decide on the Copernican theory. The cardinals of the Inquisition met on 24 February 1616 and took evidence from theological experts. They condemned the teachings of Copernicus, and Bellarmine conveyed their decision to Galileo who had not been personally involved in the trial. Galileo was forbidden to hold Copernican views. Dave, I've participated in the evolution of distributed systems of the past 10 years, DCE, CORBA, and now J2EE implementations. System level aspects are just the next iteration of the same theme. The difference being that the AOP paradigm finally let's you separate your business logic code from your distributed infrastructure. You will see. Everybody will jump on the AOP bandwagon eventually. I'm just glad JBoss is a leader this time rather than being just a J2EE chump follower. 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Bill, This is fabulous stuff. Good job. Is there a way we might be able to use the AOP xml to dynamically do your example below (as well as the clustered and remoting) for POJOs during construction time? In other words, could you not have an interceptor on a constructor pointcut that would do this for you and dynamically make the class Versionable, Clusterable, Remotable, etc. so that the actual instance you receive back has these capabilities transparently w/o having to programatically do this? The advantages of this would be that you could dynamically modify the POJO from the XML file without having to do it programmatically (of course, you could if you wanted to). That way, we can truly separate the business logic (as an example, no flames here) from the cross-cutting of concerns such as transactibility, security, remoteness, etc. Looking at the jboss-aop.xml in the testsuite - it looks like you're doing this with the Tx Interceptor on the VersionedPOJO - why not just create the VersionedPOJO in the same way and insert the Versioned Interceptor the same way? Is this possible? Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Wednesday, March 26, 2003 7:09 PM To: Jboss-Dev Subject: [JBoss-dev] AOP versioned ACID objects 1st iteration I have implemented a new AOP service for Serializable POJOs, Versioned Objects. You can transactionally version an object. If you modify the object within a transaction, this modification is not seen by other transactions. If the tx commits, the changes seen, if a rollback happens the changes are rolled back. On commit, if another tx has modified the object, the tx will rollback (OptimisticLocking). The way it works is as follows: POJO pojo = new POJO(); pojo = (POJO)org.jboss.aop.plugins.Versioned.makeVersioned(pojo); calling Versioned.makeVersioned creates a proxy that sits in front of the real object. transactionManager.begin(); pojo.callMethod(); when callMethod is invoked since there is a transaction, an interceptor creates a copy of the REAL pojo and does all further invocations on this copy. pojo.someField = 5; If you have field interception turned on, public field will also be accessed via the copy/version tm.commit(); On commit, a tx Synchronization checks to see if the version you have created is the latest and greatest. If not an org.jboss.aop.plugins.OptimisticLockFailure exception is thrown in beforeCompletion. I'm not sure how this exception is wrapped. Some other semantics: 1. All method invocations force a version to be created. You can avoid this by declared class-metadata as follows: class-metadata name=234234 group=VERSIONED class=org.jboss.test.aop.bean.VersionedPOJO method name=get.* read-onlytrue/read-only /method /class-metadata A readonly method will not cause the creation of a version and the current object will be used. An example and unit test is under testsuite/src/main/org/jboss/test/aop/bean/VersionedObjectTester.java The example object VersionedPOJO.java, has 1 interceptor pointcut declared on the class to do Tx stuff. See testsuite/src/resources/aop/META-INF/jboss-aop.xml for more details. What would be nice is to also write a TransactionalLock interceptor for versioned POJO's that have high OptimisticLock failures. 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
Re: [JBoss-dev] AOP versioned ACID objects 1st iteration
Pope Paul V ordered Bellarmine to have the Sacred Congregation of the Index decide on the Copernican theory. The cardinals of the Inquisition met on 24 February 1616 and took evidence from theological experts. They condemned the teachings of Copernicus, and Bellarmine conveyed their decision to Galileo who had not been personally involved in the trial. Galileo was forbidden to hold Copernican views. Dude, that is so funny! I was about to write that exact thing (though less elegantly) and then make some references to the Spanish Inquisition, but then I thought...what's the point... -Andy Dave, I've participated in the evolution of distributed systems of the past 10 years, DCE, CORBA, and now J2EE implementations. System level aspects are just the next iteration of the same theme. The difference being that the AOP paradigm finally let's you separate your business logic code from your distributed infrastructure. You will see. Everybody will jump on the AOP bandwagon eventually. I'm just glad JBoss is a leader this time rather than being just a J2EE chump follower. 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andrew C. Oliver Sent: Wednesday, March 26, 2003 11:14 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration Pope Paul V ordered Bellarmine to have the Sacred Congregation of the Index decide on the Copernican theory. The cardinals of the Inquisition met on 24 February 1616 and took evidence from theological experts. They condemned the teachings of Copernicus, and Bellarmine conveyed their decision to Galileo who had not been personally involved in the trial. Galileo was forbidden to hold Copernican views. Dude, that is so funny! I was about to write that exact thing (though less elegantly) and then make some references to the Spanish Inquisition, but then I thought...what's the point... Only reason it was written elegantly is that I plagarized it from the web :-0 (BTW, I liked your blog you posted out the other day...) I'd like to add that through each iteration (DCE, CORBA, J2EE, Web Services) I think the industry has learned something. There's a lot JBoss AOP can take from these specifications. Bill -Andy Dave, I've participated in the evolution of distributed systems of the past 10 years, DCE, CORBA, and now J2EE implementations. System level aspects are just the next iteration of the same theme. The difference being that the AOP paradigm finally let's you separate your business logic code from your distributed infrastructure. You will see. Everybody will jump on the AOP bandwagon eventually. I'm just glad JBoss is a leader this time rather than being just a J2EE chump follower. 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
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:07 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration Bill, This is fabulous stuff. Good job. JBoss Remoting is much more fabulous. We need to get the word out on it... Is there a way we might be able to use the AOP xml to dynamically do your example below (as well as the clustered and remoting) for POJOs during construction time? In other words, could you not have an interceptor on a constructor pointcut that would do this for you and dynamically make the class Versionable, Clusterable, Remotable, etc. so that the actual instance you receive back has these capabilities transparently w/o having to programatically do this? The advantages of this would be that you could dynamically modify the POJO from the XML file without having to do it programmatically (of course, you could if you wanted to). That way, we can truly separate the business logic (as an example, no flames here) from the cross-cutting of concerns such as transactibility, security, remoteness, etc. Looking at the jboss-aop.xml in the testsuite - it looks like you're doing this with the Tx Interceptor on the VersionedPOJO - why not just create the VersionedPOJO in the same way and insert the Versioned Interceptor the same way? Is this possible? 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. 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... Bill Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Wednesday, March 26, 2003 7:09 PM To: Jboss-Dev Subject: [JBoss-dev] AOP versioned ACID objects 1st iteration I have implemented a new AOP service for Serializable POJOs, Versioned Objects. You can transactionally version an object. If you modify the object within a transaction, this modification is not seen by other transactions. If the tx commits, the changes seen, if a rollback happens the changes are rolled back. On commit, if another tx has modified the object, the tx will rollback (OptimisticLocking). The way it works is as follows: POJO pojo = new POJO(); pojo = (POJO)org.jboss.aop.plugins.Versioned.makeVersioned(pojo); calling Versioned.makeVersioned creates a proxy that sits in front of the real object. transactionManager.begin(); pojo.callMethod(); when callMethod is invoked since there is a transaction, an interceptor creates a copy of the REAL pojo and does all further invocations on this copy. pojo.someField = 5; If you have field interception turned on, public field will also be accessed via the copy/version tm.commit(); On commit, a tx Synchronization checks to see if the version you have created is the latest and greatest. If not an org.jboss.aop.plugins.OptimisticLockFailure exception is thrown in beforeCompletion. I'm not sure how this exception is wrapped. Some other semantics: 1. All method invocations force a version to be created. You can avoid this by declared class-metadata as follows: class-metadata name=234234 group=VERSIONED class=org.jboss.test.aop.bean.VersionedPOJO method name=get.* read-onlytrue/read-only /method /class-metadata A readonly method will not cause the creation of a version and the current object will be used. An example and unit test is under testsuite/src/main/org/jboss/test/aop/bean/VersionedObjectTester.java The example object VersionedPOJO.java, has 1 interceptor pointcut declared on the class to do Tx stuff. See testsuite/src/resources/aop/META-INF/jboss-aop.xml for more details. What would be nice is to also write a TransactionalLock interceptor for versioned POJO's that have high OptimisticLock failures. 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Wednesday, March 26, 2003 11:37 PM 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:07 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration Bill, This is fabulous stuff. Good job. JBoss Remoting is much more fabulous. We need to get the word out on it... Is there a way we might be able to use the AOP xml to dynamically do your example below (as well as the clustered and remoting) for POJOs during construction time? In other words, could you not have an interceptor on a constructor pointcut that would do this for you and dynamically make the class Versionable, Clusterable, Remotable, etc. so that the actual instance you receive back has these capabilities transparently w/o having to programatically do this? The advantages of this would be that you could dynamically modify the POJO from the XML file without having to do it programmatically (of course, you could if you wanted to). That way, we can truly separate the business logic (as an example, no flames here) from the cross-cutting of concerns such as transactibility, security, remoteness, etc. Looking at the jboss-aop.xml in the testsuite - it looks like you're doing this with the Tx Interceptor on the VersionedPOJO - why not just create the VersionedPOJO in the same way and insert the Versioned Interceptor the same way? Is this possible? 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. I will write some testcases that put the whole stack together with constructor pointcuts. One more thing...I don't think the constructor pointcut approach makes sense most of the time for Remoting and Clustering. The point being that you don't want to hardcode your remotable object to a specific protocol. 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
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
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 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? 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
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Versioning -- Versioning can be done by Byte code manipulation. Instead of maintaining the state as a proxy, you can maintain the state in a list in the manipulated class. Remoting -- has to be done through proxy, but abstract the user by the Inteceptor sending the proxy based on the communication layer. Karthik -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
