[JBoss-dev] Set on abstract to generate isModified
At the aussie training (god I am still so jet-lagged from this :( the guys wanted to know if CMP 2.0 in JBoss did the automated generation of isModified() on set operations. i assume yes but just wanted to make sure. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Set on abstract to generate isModified
[marc fleury] At the aussie training (god I am still so jet-lagged from this :( the guys wanted to know if CMP 2.0 in JBoss did the automated generation of isModified() on set operations. i assume yes but just wanted to make sure. Does it check to make sure the value has actually changed? May not be useful enough in the common case, but if a setter modifies a value to the same value it already had, it'd be a nice touch if that didn't trip modified and cause JDBC actions *shrug* -- James Manning [EMAIL PROTECTED] GPG Key fingerprint = B913 2FBD 14A9 CE18 B2B7 9C8E A0BF B026 EEBB F6E4 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Set on abstract to generate isModified
This strikes as a biggy for performance. Would you mind explaining the breaking of dependency you observed... can we power our way through this? again I think this is a biggy in perf but I am largely ignorant of the way it is supposed to work. marcf |-Original Message- |From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] |Sent: Friday, February 22, 2002 1:46 PM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] Set on abstract to generate isModified | | |I don't really generate anything other then the simple DP. I have has |automatic isModified from the beginning. I have also removed all |support for isModified in the CMP 2.0 code as it breaks relationship code. | |The current implementation could be better, but this is a very low |priority. | |-dain | |marc fleury wrote: | | At the aussie training (god I am still so jet-lagged from this |:( the guys | wanted to know if CMP 2.0 in JBoss did the automated generation of | isModified() on set operations. | | i assume yes but just wanted to make sure. | | marcf | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Set on abstract to generate isModified
I completely disagree with you assessment that is is a big performance hit. In the persistence engine I know exactly which cmp fields have been changed and if any relationships have been changed. This inModified stuff is originally designed to eliminate unnecessary calls to ejbStore because it was so expensive (especially before tuned updates). With the new engine, all you avoid is a single call through the interceptor stack (~0.06 ms), and you give up on having a reliable ejbStore life cycle event. The simple isModified implementation in jaws breaks the relationships because a bean can be involved in a blind relationship where it does not have an relationship accessor. Therefore the bean provider has no way of knowing if the relationship has been modified. There is also the problem of relationship collection methods. Is modified method is just bad news for relationships, and is an attempt to solve problems we don't have in EJB 2.0. -dain P.S. marc, is the clock on your computer off by two hours or is the time zone set wrong, because your messages always show up a time stamp two hours in the future. marc fleury wrote: This strikes as a biggy for performance. Would you mind explaining the breaking of dependency you observed... can we power our way through this? again I think this is a biggy in perf but I am largely ignorant of the way it is supposed to work. marcf |-Original Message- |From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] |Sent: Friday, February 22, 2002 1:46 PM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] Set on abstract to generate isModified | | |I don't really generate anything other then the simple DP. I have has |automatic isModified from the beginning. I have also removed all |support for isModified in the CMP 2.0 code as it breaks relationship code. | |The current implementation could be better, but this is a very low |priority. | |-dain | |marc fleury wrote: | | At the aussie training (god I am still so jet-lagged from this |:( the guys | wanted to know if CMP 2.0 in JBoss did the automated generation of | isModified() on set operations. | | i assume yes but just wanted to make sure. | | marcf | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Set on abstract to generate isModified
James Manning wrote: [marc fleury] At the aussie training (god I am still so jet-lagged from this :( the guys wanted to know if CMP 2.0 in JBoss did the automated generation of isModified() on set operations. i assume yes but just wanted to make sure. Does it check to make sure the value has actually changed? May not be useful enough in the common case, but if a setter modifies a value to the same value it already had, it'd be a nice touch if that didn't trip modified and cause JDBC actions *shrug* yes. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Set on abstract to generate isModified
Dain --just to be really clear-- The fix I did for quadratic algorithm puts beans in a list to have ejbStore called if: they have a method called on them after the last find, create, or store -and- ctxContainer.getPersistenceManager().isModified(ctx) returns true. Is this accurate for cmp2 beans? As I understood your code it was, but I would like to double check. Thanks david jencks On 2002.02.22 18:00:54 -0500 Dain Sundstrom wrote: I completely disagree with you assessment that is is a big performance hit. In the persistence engine I know exactly which cmp fields have been changed and if any relationships have been changed. This inModified stuff is originally designed to eliminate unnecessary calls to ejbStore because it was so expensive (especially before tuned updates). With the new engine, all you avoid is a single call through the interceptor stack (~0.06 ms), and you give up on having a reliable ejbStore life cycle event. The simple isModified implementation in jaws breaks the relationships because a bean can be involved in a blind relationship where it does not have an relationship accessor. Therefore the bean provider has no way of knowing if the relationship has been modified. There is also the problem of relationship collection methods. Is modified method is just bad news for relationships, and is an attempt to solve problems we don't have in EJB 2.0. -dain P.S. marc, is the clock on your computer off by two hours or is the time zone set wrong, because your messages always show up a time stamp two hours in the future. marc fleury wrote: ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Set on abstract to generate isModified
David Jencks wrote: Dain --just to be really clear-- The fix I did for quadratic algorithm puts beans in a list to have ejbStore called if: they have a method called on them after the last find, create, or store -and- ctxContainer.getPersistenceManager().isModified(ctx) returns true. Is this accurate for cmp2 beans? As I understood your code it was, but I would like to double check. Yes. Changes to relationships are sent through the interceptor stack so they look like method calls, and the isModified method in the persistence manager for cmp2 always returns true. In the end it all works fine. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Set on abstract to generate isModified
|Is modified method is just bad news for relationships, and is an attempt |to solve problems we don't have in EJB 2.0. so you DO track the setters to establish the list of changed fields and not calling a blind store on the whole state. That is really what I wanted to make sure you were doing. Geezus you are all so pricky out to kill the father these days, it's anoying. I can't make a point without having all of you go no no no and then saying the same thing. whatever as long as you track setters without tuned-updates reflection, I am happy. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Set on abstract to generate isModified
Not needing an isModified was the conclusion we reached in the discussion with Marc in Sydney as well. It was nice for JAWS to improve performance, but a complete hack, because if you return false and do modify your bean you potentially lose your updates and you are messing with the EJB spec. Putting it in the set/get in CMP2.0 you get both performance, spec compliance and prevent programmers to shot themself in the foot - nice. Robert. -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 23, 2002 10:01 AM To: marc fleury Cc: Jboss-Development@Lists. Sourceforge. Net Subject: Re: [JBoss-dev] Set on abstract to generate isModified I completely disagree with you assessment that is is a big performance hit. In the persistence engine I know exactly which cmp fields have been changed and if any relationships have been changed. This inModified stuff is originally designed to eliminate unnecessary calls to ejbStore because it was so expensive (especially before tuned updates). With the new engine, all you avoid is a single call through the interceptor stack (~0.06 ms), and you give up on having a reliable ejbStore life cycle event. The simple isModified implementation in jaws breaks the relationships because a bean can be involved in a blind relationship where it does not have an relationship accessor. Therefore the bean provider has no way of knowing if the relationship has been modified. There is also the problem of relationship collection methods. Is modified method is just bad news for relationships, and is an attempt to solve problems we don't have in EJB 2.0. -dain P.S. marc, is the clock on your computer off by two hours or is the time zone set wrong, because your messages always show up a time stamp two hours in the future. marc fleury wrote: This strikes as a biggy for performance. Would you mind explaining the breaking of dependency you observed... can we power our way through this? again I think this is a biggy in perf but I am largely ignorant of the way it is supposed to work. marcf |-Original Message- |From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] |Sent: Friday, February 22, 2002 1:46 PM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] Set on abstract to generate isModified | | |I don't really generate anything other then the simple DP. I have has |automatic isModified from the beginning. I have also removed all |support for isModified in the CMP 2.0 code as it breaks relationship code. | |The current implementation could be better, but this is a very low |priority. | |-dain | |marc fleury wrote: | | At the aussie training (god I am still so jet-lagged from this |:( the guys | wanted to know if CMP 2.0 in JBoss did the automated generation of | isModified() on set operations. | | i assume yes but just wanted to make sure. | | marcf | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ** visit http://www.solution6.com visit http://www.eccountancy.com - everything for accountants. UK Customers - http://www.solution6.co.uk * This email message (and attachments) may contain information that is confidential to Solution 6. If you are not the intended recipient you cannot use, distribute or copy the message or attachments. In such a case, please notify the sender by return email immediately and erase all copies of the message and attachments. Opinions, conclusions and other information in this message and attachments that do not relate to the official business of Solution 6 are neither given nor endorsed by it. * ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
