RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
Bill,
Did you put this patch into your schedule? I checked the recent CVS tree and found
nothing about it. Thanks.
Tom
Tom,
Ok, I know what you need. Give me a few.
Bill kx
¨ºj.Û(}Æ}è§jס¶ÚþØbH zG(û %º,±×¯zZ)éí¨¥x%ËIn,uëÞfz{eËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ÏåËbú?º,±×¯zZ)éí
RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
Commit option B doesn't give you anything anyways in JBoss unless you are doing non-transactional requests on your entity beans. Since this is a rarity, I didn't put much thought into commit-b optimizations for the multiinstance interceptors. Bill -Original Message- From: Henri Chen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 9:46 AM To: [EMAIL PROTECTED] Cc: Bill Burke Subject: RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? Is this implies that there is no Option B in jboss 2.4.4 at all because option B virtually equals to option C? Henri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Tuesday, April 09, 2002 9:09 PM To: Henri Chen; [EMAIL PROTECTED] Subject: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? This is because we trash the instance. -Original Message- From: Henri Chen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 4:40 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? Dear Bill, Sorry to bother you again. This is based on the jboss 2.4.4 source code. According to the ejb 2.0 spec as seen on P.210, in Option B, the instance should only be marked as invalid state inside afterCompletion(). However, the EntityMultiInstanceSynchronizationInterceptor.java implementation of jboss 2.4.4 always calling ejbPassivate() no matter it is Option B or Option C. Henri Chen ___ 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] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
I agree. Commit option B assumes that you can synchronize the instance¡¦s state from the persistent storage at the beginning of the next transaction. We simply don't have any method to to that in 2.4.4 or the current 3.0 code, other then reload all the data. The optimistic locking code that I have planed for 3.0 will allow a quick is changed check with the database. So until then option B doesn't buy you much. -dain Bill Burke wrote: Commit option B doesn't give you anything anyways in JBoss unless you are doing non-transactional requests on your entity beans. Since this is a rarity, I didn't put much thought into commit-b optimizations for the multiinstance interceptors. Bill -Original Message- From: Henri Chen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 9:46 AM To: [EMAIL PROTECTED] Cc: Bill Burke Subject: RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? Is this implies that there is no Option B in jboss 2.4.4 at all because option B virtually equals to option C? Henri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Tuesday, April 09, 2002 9:09 PM To: Henri Chen; [EMAIL PROTECTED] Subject: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? This is because we trash the instance. -Original Message- From: Henri Chen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 4:40 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? Dear Bill, Sorry to bother you again. This is based on the jboss 2.4.4 source code. According to the ejb 2.0 spec as seen on P.210, in Option B, the instance should only be marked as invalid state inside afterCompletion(). However, the EntityMultiInstanceSynchronizationInterceptor.java implementation of jboss 2.4.4 always calling ejbPassivate() no matter it is Option B or Option C. Henri Chen ___ 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] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
I don't see how optimistic locking can have optimization advantages with commit-option B. I thought B's benefit was only for non-transactional method calls. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Tuesday, April 09, 2002 10:16 AM To: Bill Burke Cc: Henri Chen; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? I agree. Commit option B assumes that you can synchronize the instance¡¦s state from the persistent storage at the beginning of the next transaction. We simply don't have any method to to that in 2.4.4 or the current 3.0 code, other then reload all the data. The optimistic locking code that I have planed for 3.0 will allow a quick is changed check with the database. So until then option B doesn't buy you much. -dain Bill Burke wrote: Commit option B doesn't give you anything anyways in JBoss unless you are doing non-transactional requests on your entity beans. Since this is a rarity, I didn't put much thought into commit-b optimizations for the multiinstance interceptors. Bill -Original Message- From: Henri Chen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 9:46 AM To: [EMAIL PROTECTED] Cc: Bill Burke Subject: RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? Is this implies that there is no Option B in jboss 2.4.4 at all because option B virtually equals to option C? Henri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Tuesday, April 09, 2002 9:09 PM To: Henri Chen; [EMAIL PROTECTED] Subject: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? This is because we trash the instance. -Original Message- From: Henri Chen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 4:40 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? Dear Bill, Sorry to bother you again. This is based on the jboss 2.4.4 source code. According to the ejb 2.0 spec as seen on P.210, in Option B, the instance should only be marked as invalid state inside afterCompletion(). However, the EntityMultiInstanceSynchronizationInterceptor.java implementation of jboss 2.4.4 always calling ejbPassivate() no matter it is Option B or Option C. Henri Chen ___ 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
You are thinking too much in terms of real locks. If you have a large entity (lots of columns) then you can save a lot of loading time if you could check to see if the data stored in the EntityContext is still in sync with the db row. Basically you do a select to see if any of the optimistic lock columns (timestamp, sequence, or other junk) have changed. For a lot of entities this would be a huge savings. -dain Bill Burke wrote: I don't see how optimistic locking can have optimization advantages with commit-option B. I thought B's benefit was only for non-transactional method calls. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dain Sundstrom Sent: Tuesday, April 09, 2002 10:16 AM To: Bill Burke Cc: Henri Chen; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? I agree. Commit option B assumes that you can synchronize the instance¡¦s state from the persistent storage at the beginning of the next transaction. We simply don't have any method to to that in 2.4.4 or the current 3.0 code, other then reload all the data. The optimistic locking code that I have planed for 3.0 will allow a quick is changed check with the database. So until then option B doesn't buy you much. -dain Bill Burke wrote: Commit option B doesn't give you anything anyways in JBoss unless you are doing non-transactional requests on your entity beans. Since this is a rarity, I didn't put much thought into commit-b optimizations for the multiinstance interceptors. Bill -Original Message- From: Henri Chen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 9:46 AM To: [EMAIL PROTECTED] Cc: Bill Burke Subject: RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? Is this implies that there is no Option B in jboss 2.4.4 at all because option B virtually equals to option C? Henri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Tuesday, April 09, 2002 9:09 PM To: Henri Chen; [EMAIL PROTECTED] Subject: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? This is because we trash the instance. -Original Message- From: Henri Chen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 4:40 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? Dear Bill, Sorry to bother you again. This is based on the jboss 2.4.4 source code. According to the ejb 2.0 spec as seen on P.210, in Option B, the instance should only be marked as invalid state inside afterCompletion(). However, the EntityMultiInstanceSynchronizationInterceptor.java implementation of jboss 2.4.4 always calling ejbPassivate() no matter it is Option B or Option C. Henri Chen ___ 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 ___ 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] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
I agree, but the problem is that there is very little we can reuse. We have to throw out all cached data, because we currently have no way to verify if it is still in sync with the database. -dain marc fleury wrote: |Is this implies that there is no Option B in jboss 2.4.4 at all |because option B virtually equals to option C? No, in option B we still keep the instance if you are going to reuse it. We trash the instance only when we change identities (i.e there is no reuse). Different things. marcf | |Henri | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill |Burke |Sent: Tuesday, April 09, 2002 9:09 PM |To: Henri Chen; [EMAIL PROTECTED] |Subject: [JBoss-dev] RE: Bug in |EntityMultiInstanceSynchronizationInterceptor.java ? | | |This is because we trash the instance. | | -Original Message- | From: Henri Chen [mailto:[EMAIL PROTECTED]] | Sent: Tuesday, April 09, 2002 4:40 AM | To: [EMAIL PROTECTED] | Cc: [EMAIL PROTECTED] | Subject: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? | | | Dear Bill, | | Sorry to bother you again. This is based on the jboss 2.4.4 source code. | | According to the ejb 2.0 spec as seen on P.210, in Option B, the | instance should only be marked as invalid state inside | afterCompletion(). However, the | EntityMultiInstanceSynchronizationInterceptor.java | implementation of jboss 2.4.4 always calling ejbPassivate() no | matter it is Option B or Option C. | | Henri Chen | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development? ??Én??ׯzZ)??¨¥ ?x%?In??ׯzZ)?íþX¬¶Ïì¢êÜy??çzØm???ùb²Û??«qçè?-³ùb²Ø§~?n??ׯz Z)|? ___ 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] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
|I agree, but the problem is that there is very little we can reuse. We |have to throw out all cached data, because we currently have no way to |verify if it is still in sync with the database. that is correct, and as you state a timestamp or incremented field as a default for tables we create would make a lot of sense. This is for the 3.11 for workgroups version... for 3.0 final it will be like the 2.4 codebase and basta. Let's get this puppy out of the door. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
you can save a lot of loading time if you could check to see if the data stored in the EntityContext is still in sync with the db row. Dain, you already answered the reason for Option B. However, when you said very little we can reuse, you seems to assume CMP. In our cases, we use Option B and BMP that uses versioning for optimistic lock. Surprisedly, in the current implementation of JBoss, our optimistic lock not only gets nothing, but even hurts the performance (because an extra select must be issued). Please re-think the priority to support Option B. _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12462 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
Guys, You are assuming CMP only. But how about BMP? If someone wants to implement a timestamp or rowversion in his table and reuse the instance under Option B, the current JBoss 2.4.4 implementation would not be able to support it. Henri -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 10, 2002 12:44 AM To: Dain Sundstrom Cc: Henri Chen; [EMAIL PROTECTED]; Bill Burke Subject: RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? |I agree, but the problem is that there is very little we can reuse. We |have to throw out all cached data, because we currently have no way to |verify if it is still in sync with the database. that is correct, and as you state a timestamp or incremented field as a default for tables we create would make a lot of sense. This is for the 3.11 for workgroups version... for 3.0 final it will be like the 2.4 codebase and basta. Let's get this puppy out of the door. marcf [¢Ë z÷¥¢ÙX§X¬´è²Ç^½éh¦g§¶X¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣøÛ¢Ë z÷¥¢
RE: RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
Good points Tom.Do you do your optimistic lock check on both ejbLoad and ejbStore?I suggest using the following container configuration with your optimistic locking scheme. If you try it out, let me know how it works out. Thanks, Bill container-configuration container-nameStandard CMP EntityBean/container-name call-loggingfalse/call-logging container-invokerorg.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker/container-invoker container-interceptors interceptororg.jboss.ejb.plugins.LogInterceptor/interceptor interceptororg.jboss.ejb.plugins.SecurityInterceptor/interceptor interceptororg.jboss.ejb.plugins.TxInterceptorCMT/interceptor interceptor metricsEnabled="true"org.jboss.ejb.plugins.MetricsInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityLockInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityMultiInstanceInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityMultiInstanceSynchronizationInterceptor/interceptor /container-interceptors instance-poolorg.jboss.ejb.plugins.EntityInstancePool/instance-pool instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache persistence-managerorg.jboss.ejb.plugins.jaws.JAWSPersistenceManager/persistence-manager transaction-managerorg.jboss.tm.TxManager/transaction-manager locking-policyorg.jboss.ejb.plugins.lock.MethodOnlyEJBLock/locking-policy container-invoker-conf RMIObjectPort/RMIObjectPort OptimizedTrue/Optimized /container-invoker-conf container-cache-conf cache-policyorg.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy/cache-policy cache-policy-conf min-capacity50/min-capacity max-capacity1000/max-capacity overager-period300/overager-period max-bean-age600/max-bean-age resizer-period400/resizer-period max-cache-miss-period60/max-cache-miss-period min-cache-miss-period1/min-cache-miss-period cache-load-factor0.75/cache-load-factor /cache-policy-conf /container-cache-conf container-pool-conf MaximumSize100/MaximumSize MinimumSize10/MinimumSize /container-pool-conf commit-optionB/commit-option /container-configuration -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of tom yeh Sent: Tuesday, April 09, 2002 8:58 PM To: [EMAIL PROTECTED] Subject: Re: RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? you can save a lot of loading time if you could check to see if the data stored in the EntityContext is still in sync with the db row. Dain, you already answered the reason for Option B. However, when you said "very little we can reuse", you seems to assume CMP. In our cases, we use Option B and BMP that uses versioning for optimistic lock. Surprisedly, in the current implementation of JBoss, our optimistic lock not only gets nothing, but even hurts the performance (because an extra select must be issued). Please re-think the priority to support Option B. _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12462 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
Tom, The commit option code actually Bill's. I don't know if Bill will be able to look at this before the friday release, so Tom can you submit a patch? -dain tom yeh wrote: you can save a lot of loading time if you could check to see if the data stored in the EntityContext is still in sync with the db row. Dain, you already answered the reason for Option B. However, when you said very little we can reuse, you seems to assume CMP. In our cases, we use Option B and BMP that uses versioning for optimistic lock. Surprisedly, in the current implementation of JBoss, our optimistic lock not only gets nothing, but even hurts the performance (because an extra select must be issued). Please re-think the priority to support Option B. _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12462 ___ 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] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
Bill, thanks for configuration, but it is the same as what I am trying. gt;Henri wrote: gt;the EntityMultiInstanceSynchronizationInterceptor.java gt;implementation of jboss 2.4.4 always calling gt;ejbPassivate() no matter it is Option B or Option C. After logging messages and examining the codes (in afterCompletion()), I found both option B and C passivate beans as soon as a transaction complete. A quick patch is to move container.getPersistenceManager().passivateEntity(ctx) under C_COMMIT_OPTION only. However, it might not work since container.getInstancePool().free(ctx) seems count on passivateEntity being called -- I am not sure. You are the expert. _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12462 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ?
Tom, Ok, I know what you need. Give me a few. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of tom yeh Sent: Tuesday, April 09, 2002 10:24 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] RE: Bug in EntityMultiInstanceSynchronizationInterceptor.java ? Bill, thanks for configuration, but it is the same as what I am trying. gt;Henri wrote: gt;the EntityMultiInstanceSynchronizationInterceptor.java gt;implementation of jboss 2.4.4 always calling gt;ejbPassivate() no matter it is Option B or Option C. After logging messages and examining the codes (in afterCompletion()), I found both option B and C passivate beans as soon as a transaction complete. A quick patch is to move container.getPersistenceManager().passivateEntity(ctx) under C_COMMIT_OPTION only. However, it might not work since container.getInstancePool().free(ctx) seems count on passivateEntity being called -- I am not sure. You are the expert. _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12462 ___ 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
