From issues at jboss.org Mon Mar 19 14:45:00 2018 From: issues at jboss.org (Jan-Willem Gmelig Meyling (JIRA)) Date: Mon, 19 Mar 2018 14:45:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed In-Reply-To: References: Message-ID: Jan-Willem Gmelig Meyling created CDI-724: --------------------------------------------- Summary: Transactional observers fired in inconsistent manner when synchronisation cannot be placed Key: CDI-724 URL: https://issues.jboss.org/browse/CDI-724 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 2.0 .Final Reporter: Jan-Willem Gmelig Meyling Priority: Minor I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be finished during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity listeners (which are typically invoked during FLUSH, which is on itself is triggered through a transaction synchronisation). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 19 14:47:00 2018 From: issues at jboss.org (Jan-Willem Gmelig Meyling (JIRA)) Date: Mon, 19 Mar 2018 14:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Description: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity listeners (which are typically invoked during FLUSH, which is on itself is triggered through a transaction synchronisation). was: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be finished during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity listeners (which are typically invoked during FLUSH, which is on itself is triggered through a transaction synchronisation). > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > Priority: Minor > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the transactional observer was never invoked in the first place. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. > While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity listeners (which are typically invoked during FLUSH, which is on itself is triggered through a transaction synchronisation). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 19 14:47:00 2018 From: issues at jboss.org (Jan-Willem Gmelig Meyling (JIRA)) Date: Mon, 19 Mar 2018 14:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Description: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity listeners (which are typically invoked during FLUSH, which is on itself is triggered through a transaction synchronisation). was: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity listeners (which are typically invoked during FLUSH, which is on itself is triggered through a transaction synchronisation). > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > Priority: Minor > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. > While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity listeners (which are typically invoked during FLUSH, which is on itself is triggered through a transaction synchronisation). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 19 14:48:00 2018 From: issues at jboss.org (Jan-Willem Gmelig Meyling (JIRA)) Date: Mon, 19 Mar 2018 14:48:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Description: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity listeners (which are typically invoked during FLUSH, which is itself is triggered through a transaction synchronisation). was: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity listeners (which are typically invoked during FLUSH, which is on itself is triggered through a transaction synchronisation). > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > Priority: Minor > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. > While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity listeners (which are typically invoked during FLUSH, which is itself is triggered through a transaction synchronisation). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 19 14:52:00 2018 From: issues at jboss.org (Jan-Willem Gmelig Meyling (JIRA)) Date: Mon, 19 Mar 2018 14:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Description: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which is itself is triggered through a transaction synchronisation). was: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity listeners (which are typically invoked during FLUSH, which is itself is triggered through a transaction synchronisation). > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > Priority: Minor > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. > While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which is itself is triggered through a transaction synchronisation). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 19 14:53:01 2018 From: issues at jboss.org (Jan-Willem Gmelig Meyling (JIRA)) Date: Mon, 19 Mar 2018 14:53:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Description: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). was: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which is itself is triggered through a transaction synchronisation). > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > Priority: Minor > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. > While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 19 14:54:01 2018 From: issues at jboss.org (Jan-Willem Gmelig Meyling (JIRA)) Date: Mon, 19 Mar 2018 14:54:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Priority: Major (was: Minor) > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. > While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 19 14:55:00 2018 From: issues at jboss.org (Jan-Willem Gmelig Meyling (JIRA)) Date: Mon, 19 Mar 2018 14:55:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Description: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). was: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction succeeded or is about to succeed. This may confuse users that want to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect to use AFTER_FAILIURE if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. > While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 19 14:56:03 2018 From: issues at jboss.org (Jan-Willem Gmelig Meyling (JIRA)) Date: Mon, 19 Mar 2018 14:56:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Description: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place, even though the transaction did commit. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). was: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect to use AFTER_FAILIURE if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place, even though the transaction did commit. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. > While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 19 14:59:02 2018 From: issues at jboss.org (Jan-Willem Gmelig Meyling (JIRA)) Date: Mon, 19 Mar 2018 14:59:02 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Description: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect the AFTER_FAILIURE observer to be invoked if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place, even though the transaction did commit. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). was: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect to use AFTER_FAILIURE if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place, even though the transaction did commit. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect the AFTER_FAILIURE observer to be invoked if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place, even though the transaction did commit. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. > While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Mar 22 09:45:00 2018 From: issues at jboss.org (Jan-Willem Gmelig Meyling (JIRA)) Date: Thu, 22 Mar 2018 09:45:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-724) Transactional observers fired in inconsistent manner when synchronisation cannot be placed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Willem Gmelig Meyling updated CDI-724: ------------------------------------------ Description: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect the AFTER_FAILIURE observer to be invoked if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place, even though the transaction did commit. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. It also should be pretty easy to work around by just placing a single synchronisation, and queueing transactional observers in a transaction scoped queue. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). was: I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? This choice has to some very unexpected side effects, namely: * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect the AFTER_FAILIURE observer to be invoked if and only if the actual transaction rolled back. * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place, even though the transaction did commit. In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). > Transactional observers fired in inconsistent manner when synchronisation cannot be placed > ------------------------------------------------------------------------------------------ > > Key: CDI-724 > URL: https://issues.jboss.org/browse/CDI-724 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0 .Final > Reporter: Jan-Willem Gmelig Meyling > > I have noticed some unexpected behaviour with the current workings of transactional observers. I have initially reported these issues under WELD-2444 , where [~mkouba] pointed out that WELD simply followed the CDI spec here: > ??If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped.?? > This choice has to some very unexpected side effects, namely: > * If the synchronisation cannot be placed, AFTER_FAILURE observers will be invoked, even if the actual transaction already succeeded or is about to succeed. This may confuse users that expect the AFTER_FAILIURE observer to be invoked if and only if the actual transaction rolled back. > * If the synchronisation cannot be placed, AFTER_FAILURE and AFTER_COMPLETION will be invoked immediately. This may confuse users that expect the actual transaction to be completed during the execution of the AFTER_FAILURE and AFTER_COMPLETION observers. Now, these observers may be invoked while still committing or rolling back. > * If the synchronisation cannot be placed, the exception is swallowed silently (with the only mechanism to observe the failure being the unfortunate invocation of the AFTER_FAILURE observer). This may make it very difficult for someone trying to figure out why the AFTER_SUCCESS transactional observer was never invoked in the first place, even though the transaction did commit. > In my opinion would be best to just throw an exception if the synchronisation cannot be placed, all of the above quirks will then be resolved. It also should be pretty easy to work around by just placing a single synchronisation, and queueing transactional observers in a transaction scoped queue. > While at it: the issue originates from the fact that the synchronisation couldn't be added during the COMMITTING state. While I do understand this limitation, I think it might be worthwhile to consider to use an interposed (run last) synchronisation rather than plain transaction synchronisations. This would AFAIK also allow placing additional synchronisations while processing the existing synchronisations (except the interposed synchronisations that is). This can for example come in handy, when fireing events from JPA entity lifecycle listeners (which are typically invoked during FLUSH, which itself is triggered through a transaction synchronisation). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Mar 25 09:41:00 2018 From: issues at jboss.org (arjan tijms (JIRA)) Date: Sun, 25 Mar 2018 09:41:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-610) Add API to obtain current injection point from Bean#create In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550989#comment-13550989 ] arjan tijms commented on CDI-610: --------------------------------- That sounds like a good plan, and it?s basically how the original method worked (more or less). Can we target this for 2.1? > Add API to obtain current injection point from Bean#create > ---------------------------------------------------------- > > Key: CDI-610 > URL: https://issues.jboss.org/browse/CDI-610 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: arjan tijms > > There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean#create}}. > A previously somewhat accepted way (though not specified) was: > {code} > Bean bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); > InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext); > {code} > This however broke in some version of Weld. > Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}. > Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injection-point-from-Bean-create-td5710505i20.html -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 26 03:01:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 26 Mar 2018 03:01:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-610) Add API to obtain current injection point from Bean#create In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-610: ----------------------------- Fix Version/s: 2.1 (Discussion) > Add API to obtain current injection point from Bean#create > ---------------------------------------------------------- > > Key: CDI-610 > URL: https://issues.jboss.org/browse/CDI-610 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Reporter: arjan tijms > Fix For: 2.1 (Discussion) > > > There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean#create}}. > A previously somewhat accepted way (though not specified) was: > {code} > Bean bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class)); > InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext); > {code} > This however broke in some version of Weld. > Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}. > Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injection-point-from-Bean-create-td5710505i20.html -- This message was sent by Atlassian JIRA (v7.5.0#75005)