RE: WebSphere and transaction managers
Does OpenJPA need to provide this level of support for all TM's? That's what I meant by my question. I don't think that OpenJPA *needs* to, but it certainly will improve the out-of-the-box experience for WAS users. Are there any public WAS hooks that we can use to automatically deploy a SLSB into a WAS environment during OpenJPA startup? In any event, there's an easy workaround right now (use the internal WAS methods, as outlined in the JIRA), and there will be another easy workaround soon (use non-jta-data-source). -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Kevin Sutter [mailto:[EMAIL PROTECTED] Sent: Monday, February 19, 2007 6:54 PM To: open-jpa-dev@incubator.apache.org Subject: Re: WebSphere and transaction managers Craig, On 2/19/07, Craig L Russell [EMAIL PROTECTED] wrote: On Feb 19, 2007, at 4:37 PM, Kevin Sutter wrote: On 2/19/07, Patrick Linskey [EMAIL PROTECTED] wrote: Maybe we should add a method to our ManagedRuntime interface to accept a Runnable that should be run in a separate transaction, and migrate our code to use that approach. That way, the WASManagedRuntime could do what Craig outlined, and other ManagedRuntime impls could retain their current behavior. Although this approach is probably workable, this sounds more complicated than just requiring the use of the non-jta-data-source element. WebSphere will eventually support the non-jta-data-source (supposedly in the next Beta of the EJB3 Feature Pack). This would be welcome news, indeed. Wouldn't that be the preferred (and spec compliant) method of nesting transactions? I think so. I suppose since OpenJPA already supports this suspension via other TM's, is it our desire to support this mechanism for all TM's? I think so. Is WAS the only application server that doesn't support non-JTA DataSource? Craig, I meant the ability to suspend a transaction. It seems that OpenJPA has provided for suspending of transactions via various API's (some external, some internal). So, it seems that some TM's allow for suspension of in-flight transactions, while others (like WAS) does not. At least not via public API's. Does OpenJPA need to provide this level of support for all TM's? That's what I meant by my question. Craig Kevin On 2/19/07, Patrick Linskey [EMAIL PROTECTED] wrote: I would have to better understand OpenJPA's need for the transaction suspension before determining whether there are alternatives available. The use case is that if we can suspend the tx, then the user doesn't need to provide a non-JTA data source. The idea is to create an EJB component solely for the purpose of suspending a transaction. This could be a Stateless Session Bean that defines a method declared as Transaction Not Supported. Interesting. We could even mark the method as @RequiresNew, thus letting the container take care of demarcation. Certainly an interesting approach for providing similar ease-of-use in a WebSphere environment. Maybe we should add a method to our ManagedRuntime interface to accept a Runnable that should be run in a separate transaction, and migrate our code to use that approach. That way, the WASManagedRuntime could do what Craig outlined, and other ManagedRuntime impls could retain their current behavior. -Patrick -- Patrick Linskey BEA Systems, Inc. _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, February 19, 2007 8:33 AM To: open-jpa-dev@incubator.apache.org Subject: Re: WebSphere and transaction managers It is possible to suspend a transaction
Re: WebSphere and transaction managers
The WebSphere Transaction API does not allow for suspension of a transaction. Even if we move to the official JPA transaction API (TransactionSynchronizationRegistry), there is no suspend method available. I would have to better understand OpenJPA's need for the transaction suspension before determining whether there are alternatives available. On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: From what the user said, it sounds like another solution is to use a different ManagedRuntime that allows suspension. My guess is that this is not an official IBM API, and is the reason that we're not using it. Is there some other official means by which we could change WASManagedRuntime to allow suspend etc.? In short, if we solve OPENJPA-149, then we have the easiest-of-all pathways covered, and OPENJPA-153 is less important. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Albert Lee [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 11:21 AM To: open-jpa-dev@incubator.apache.org Subject: Re: WebSphere and transaction managers This is known problem in WAS. The reason is data source created in WAS is always enlisted in the current global transaction, therefore RESOURCE_LOCAL persistence unit using WAS data source triggers the observed behavior. This limitation will be corrected in the WAS EJB3 Feature Pack and future releases. Immediate solution is not to specify the non-jta-data-source in the persistence unit but replace with connection information using properties openjpa.ConnectionUserName openjpa.ConnectionPassword openjpa.ConnectionURL openjpa.ConnectionDriverName It is not the ideal solution, but functional. Albert Lee On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, It looks like the new WebSphere transaction manager lookup code is missing some functionality available elsewhere. See OPENJPA-149 (https://issues.apache.org/jira/browse/OPENJPA-149) and OPENJPA-153 (https://issues.apache.org/jira/browse/OPENJPA-153) for details. The key problems are: OPENJPA-149: the WASManagedRuntime class throws exceptions on some methods, preventing OpenJPA from being able to suspend transactions OPENJPA-153: even when specifying a non-JTA data source, the data source returned does not allow commits. It does seem like the behavior of the data source is at least a bit different than the JTA data source, since OpenJPA is able to call setAutoCommit(). These seem like usability issues with WAS. I'm hoping that someone with more WAS knowledge than me can resolve the issues easily. Any takers? -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: WebSphere and transaction managers
It is possible to suspend a transaction by the standard Java EE technique. Unfortunately, this might be considered a hack, but AFAIK it's perfectly legal. The idea is to create an EJB component solely for the purpose of suspending a transaction. This could be a Stateless Session Bean that defines a method declared as Transaction Not Supported. The method invocation would contain a runnable as an argument which the execution of the method would then run. Once the runnable completed, returning from the method would resume the suspended transaction. If needed, an Object returned from the method could contain the results of the method. Craig On Feb 19, 2007, at 8:14 AM, Kevin Sutter wrote: The WebSphere Transaction API does not allow for suspension of a transaction. Even if we move to the official JPA transaction API (TransactionSynchronizationRegistry), there is no suspend method available. I would have to better understand OpenJPA's need for the transaction suspension before determining whether there are alternatives available. On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: From what the user said, it sounds like another solution is to use a different ManagedRuntime that allows suspension. My guess is that this is not an official IBM API, and is the reason that we're not using it. Is there some other official means by which we could change WASManagedRuntime to allow suspend etc.? In short, if we solve OPENJPA-149, then we have the easiest-of-all pathways covered, and OPENJPA-153 is less important. -Patrick -- Patrick Linskey BEA Systems, Inc. _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Albert Lee [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 11:21 AM To: open-jpa-dev@incubator.apache.org Subject: Re: WebSphere and transaction managers This is known problem in WAS. The reason is data source created in WAS is always enlisted in the current global transaction, therefore RESOURCE_LOCAL persistence unit using WAS data source triggers the observed behavior. This limitation will be corrected in the WAS EJB3 Feature Pack and future releases. Immediate solution is not to specify the non-jta-data-source in the persistence unit but replace with connection information using properties openjpa.ConnectionUserName openjpa.ConnectionPassword openjpa.ConnectionURL openjpa.ConnectionDriverName It is not the ideal solution, but functional. Albert Lee On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, It looks like the new WebSphere transaction manager lookup code is missing some functionality available elsewhere. See OPENJPA-149 (https://issues.apache.org/jira/browse/OPENJPA-149) and OPENJPA-153 (https://issues.apache.org/jira/browse/ OPENJPA-153) for details. The key problems are: OPENJPA-149: the WASManagedRuntime class throws exceptions on some methods, preventing OpenJPA from being able to suspend transactions OPENJPA-153: even when specifying a non-JTA data source, the data source returned does not allow commits. It does seem like the behavior of the data source is at least a bit different than the JTA data source, since OpenJPA is able to call setAutoCommit(). These seem like usability issues with WAS. I'm hoping that someone with more WAS knowledge than me can resolve the issues easily. Any takers? -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: WebSphere and transaction managers
Excellent use of the Java EE features! :-) Kevin On 2/19/07, Craig L Russell [EMAIL PROTECTED] wrote: It is possible to suspend a transaction by the standard Java EE technique. Unfortunately, this might be considered a hack, but AFAIK it's perfectly legal. The idea is to create an EJB component solely for the purpose of suspending a transaction. This could be a Stateless Session Bean that defines a method declared as Transaction Not Supported. The method invocation would contain a runnable as an argument which the execution of the method would then run. Once the runnable completed, returning from the method would resume the suspended transaction. If needed, an Object returned from the method could contain the results of the method. Craig On Feb 19, 2007, at 8:14 AM, Kevin Sutter wrote: The WebSphere Transaction API does not allow for suspension of a transaction. Even if we move to the official JPA transaction API (TransactionSynchronizationRegistry), there is no suspend method available. I would have to better understand OpenJPA's need for the transaction suspension before determining whether there are alternatives available. On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: From what the user said, it sounds like another solution is to use a different ManagedRuntime that allows suspension. My guess is that this is not an official IBM API, and is the reason that we're not using it. Is there some other official means by which we could change WASManagedRuntime to allow suspend etc.? In short, if we solve OPENJPA-149, then we have the easiest-of-all pathways covered, and OPENJPA-153 is less important. -Patrick -- Patrick Linskey BEA Systems, Inc. _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Albert Lee [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 11:21 AM To: open-jpa-dev@incubator.apache.org Subject: Re: WebSphere and transaction managers This is known problem in WAS. The reason is data source created in WAS is always enlisted in the current global transaction, therefore RESOURCE_LOCAL persistence unit using WAS data source triggers the observed behavior. This limitation will be corrected in the WAS EJB3 Feature Pack and future releases. Immediate solution is not to specify the non-jta-data-source in the persistence unit but replace with connection information using properties openjpa.ConnectionUserName openjpa.ConnectionPassword openjpa.ConnectionURL openjpa.ConnectionDriverName It is not the ideal solution, but functional. Albert Lee On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, It looks like the new WebSphere transaction manager lookup code is missing some functionality available elsewhere. See OPENJPA-149 (https://issues.apache.org/jira/browse/OPENJPA-149) and OPENJPA-153 (https://issues.apache.org/jira/browse/ OPENJPA-153) for details. The key problems are: OPENJPA-149: the WASManagedRuntime class throws exceptions on some methods, preventing OpenJPA from being able to suspend transactions OPENJPA-153: even when specifying a non-JTA data source, the data source returned does not allow commits. It does seem like the behavior of the data source is at least a bit different than the JTA data source, since OpenJPA is able to call setAutoCommit(). These seem like usability issues with WAS. I'm hoping that someone with more WAS knowledge than me can resolve the issues easily. Any takers? -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: WebSphere and transaction managers
Hi Kevin, Actually, I'll recant. This would not be a hack, because it does guarantee that the suspension of the transaction is only for the duration of the method call. IIRC, when we were discussing the functionality of the TransactionSynchronizationRegistry, and considered adding useful features like suspend and resume, there were objections that this might result in unmatched suspend/resume pairs, which would be a reasonable use case. The biggest downside to the proposal here is that it requires more setup in a server environment. The suspend/resume component would have to be deployed in each ear where it was needed, or deployed as a shared component (which is still not portable Java EE behavior IIRC). Craig On Feb 19, 2007, at 12:37 PM, Kevin Sutter wrote: Excellent use of the Java EE features! :-) Kevin On 2/19/07, Craig L Russell [EMAIL PROTECTED] wrote: It is possible to suspend a transaction by the standard Java EE technique. Unfortunately, this might be considered a hack, but AFAIK it's perfectly legal. The idea is to create an EJB component solely for the purpose of suspending a transaction. This could be a Stateless Session Bean that defines a method declared as Transaction Not Supported. The method invocation would contain a runnable as an argument which the execution of the method would then run. Once the runnable completed, returning from the method would resume the suspended transaction. If needed, an Object returned from the method could contain the results of the method. Craig On Feb 19, 2007, at 8:14 AM, Kevin Sutter wrote: The WebSphere Transaction API does not allow for suspension of a transaction. Even if we move to the official JPA transaction API (TransactionSynchronizationRegistry), there is no suspend method available. I would have to better understand OpenJPA's need for the transaction suspension before determining whether there are alternatives available. On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: From what the user said, it sounds like another solution is to use a different ManagedRuntime that allows suspension. My guess is that this is not an official IBM API, and is the reason that we're not using it. Is there some other official means by which we could change WASManagedRuntime to allow suspend etc.? In short, if we solve OPENJPA-149, then we have the easiest-of-all pathways covered, and OPENJPA-153 is less important. -Patrick -- Patrick Linskey BEA Systems, Inc. _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Albert Lee [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 11:21 AM To: open-jpa-dev@incubator.apache.org Subject: Re: WebSphere and transaction managers This is known problem in WAS. The reason is data source created in WAS is always enlisted in the current global transaction, therefore RESOURCE_LOCAL persistence unit using WAS data source triggers the observed behavior. This limitation will be corrected in the WAS EJB3 Feature Pack and future releases. Immediate solution is not to specify the non-jta-data-source in the persistence unit but replace with connection information using properties openjpa.ConnectionUserName openjpa.ConnectionPassword openjpa.ConnectionURL openjpa.ConnectionDriverName It is not the ideal solution, but functional. Albert Lee On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, It looks like the new WebSphere transaction manager lookup code is missing some functionality available elsewhere. See OPENJPA-149 (https://issues.apache.org/jira/browse/OPENJPA-149) and OPENJPA-153 (https://issues.apache.org/jira/browse/ OPENJPA-153) for details. The key problems are: OPENJPA-149: the WASManagedRuntime class throws exceptions on some methods, preventing OpenJPA from being able to suspend transactions OPENJPA-153: even when specifying a non-JTA data source, the data source returned does not allow commits. It does seem like the behavior of the data source is at least a bit different than the JTA data source, since OpenJPA is able to call setAutoCommit(). These seem like usability issues with WAS. I'm hoping that someone with more WAS knowledge than me can resolve the issues easily. Any takers? -Patrick -- Patrick Linskey BEA Systems, Inc
Re: WebSphere and transaction managers
I understand. The concerns with the unmatched suspend/resume are known within WebSphere circles quite well. I'm sure IBM was one of the voices that objected to this functionality. :-) I haven't had the time yet, but I want to understand the need for the suspend/resume functionality within OpenJPA. In my mind, it shouldn't be necessary. But, I haven't put a whole lot of thought into it yet... Kevin On 2/19/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, Actually, I'll recant. This would not be a hack, because it does guarantee that the suspension of the transaction is only for the duration of the method call. IIRC, when we were discussing the functionality of the TransactionSynchronizationRegistry, and considered adding useful features like suspend and resume, there were objections that this might result in unmatched suspend/resume pairs, which would be a reasonable use case. The biggest downside to the proposal here is that it requires more setup in a server environment. The suspend/resume component would have to be deployed in each ear where it was needed, or deployed as a shared component (which is still not portable Java EE behavior IIRC). Craig On Feb 19, 2007, at 12:37 PM, Kevin Sutter wrote: Excellent use of the Java EE features! :-) Kevin On 2/19/07, Craig L Russell [EMAIL PROTECTED] wrote: It is possible to suspend a transaction by the standard Java EE technique. Unfortunately, this might be considered a hack, but AFAIK it's perfectly legal. The idea is to create an EJB component solely for the purpose of suspending a transaction. This could be a Stateless Session Bean that defines a method declared as Transaction Not Supported. The method invocation would contain a runnable as an argument which the execution of the method would then run. Once the runnable completed, returning from the method would resume the suspended transaction. If needed, an Object returned from the method could contain the results of the method. Craig On Feb 19, 2007, at 8:14 AM, Kevin Sutter wrote: The WebSphere Transaction API does not allow for suspension of a transaction. Even if we move to the official JPA transaction API (TransactionSynchronizationRegistry), there is no suspend method available. I would have to better understand OpenJPA's need for the transaction suspension before determining whether there are alternatives available. On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: From what the user said, it sounds like another solution is to use a different ManagedRuntime that allows suspension. My guess is that this is not an official IBM API, and is the reason that we're not using it. Is there some other official means by which we could change WASManagedRuntime to allow suspend etc.? In short, if we solve OPENJPA-149, then we have the easiest-of-all pathways covered, and OPENJPA-153 is less important. -Patrick -- Patrick Linskey BEA Systems, Inc. _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Albert Lee [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 11:21 AM To: open-jpa-dev@incubator.apache.org Subject: Re: WebSphere and transaction managers This is known problem in WAS. The reason is data source created in WAS is always enlisted in the current global transaction, therefore RESOURCE_LOCAL persistence unit using WAS data source triggers the observed behavior. This limitation will be corrected in the WAS EJB3 Feature Pack and future releases. Immediate solution is not to specify the non-jta-data-source in the persistence unit but replace with connection information using properties openjpa.ConnectionUserName openjpa.ConnectionPassword openjpa.ConnectionURL openjpa.ConnectionDriverName It is not the ideal solution, but functional. Albert Lee On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, It looks like the new WebSphere transaction manager lookup code is missing some functionality available elsewhere. See OPENJPA-149 (https://issues.apache.org/jira/browse/OPENJPA-149) and OPENJPA-153 (https://issues.apache.org/jira/browse/ OPENJPA-153) for details. The key problems are: OPENJPA-149: the WASManagedRuntime class throws exceptions on some methods, preventing OpenJPA from being able to suspend
RE: WebSphere and transaction managers
I would have to better understand OpenJPA's need for the transaction suspension before determining whether there are alternatives available. The use case is that if we can suspend the tx, then the user doesn't need to provide a non-JTA data source. The idea is to create an EJB component solely for the purpose of suspending a transaction. This could be a Stateless Session Bean that defines a method declared as Transaction Not Supported. Interesting. We could even mark the method as @RequiresNew, thus letting the container take care of demarcation. Certainly an interesting approach for providing similar ease-of-use in a WebSphere environment. Maybe we should add a method to our ManagedRuntime interface to accept a Runnable that should be run in a separate transaction, and migrate our code to use that approach. That way, the WASManagedRuntime could do what Craig outlined, and other ManagedRuntime impls could retain their current behavior. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, February 19, 2007 8:33 AM To: open-jpa-dev@incubator.apache.org Subject: Re: WebSphere and transaction managers It is possible to suspend a transaction by the standard Java EE technique. Unfortunately, this might be considered a hack, but AFAIK it's perfectly legal. The idea is to create an EJB component solely for the purpose of suspending a transaction. This could be a Stateless Session Bean that defines a method declared as Transaction Not Supported. The method invocation would contain a runnable as an argument which the execution of the method would then run. Once the runnable completed, returning from the method would resume the suspended transaction. If needed, an Object returned from the method could contain the results of the method. Craig On Feb 19, 2007, at 8:14 AM, Kevin Sutter wrote: The WebSphere Transaction API does not allow for suspension of a transaction. Even if we move to the official JPA transaction API (TransactionSynchronizationRegistry), there is no suspend method available. I would have to better understand OpenJPA's need for the transaction suspension before determining whether there are alternatives available. On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: From what the user said, it sounds like another solution is to use a different ManagedRuntime that allows suspension. My guess is that this is not an official IBM API, and is the reason that we're not using it. Is there some other official means by which we could change WASManagedRuntime to allow suspend etc.? In short, if we solve OPENJPA-149, then we have the easiest-of-all pathways covered, and OPENJPA-153 is less important. -Patrick -- Patrick Linskey BEA Systems, Inc. _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Albert Lee [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 11:21 AM To: open-jpa-dev@incubator.apache.org Subject: Re: WebSphere and transaction managers This is known problem in WAS. The reason is data source created in WAS is always enlisted in the current global transaction, therefore RESOURCE_LOCAL persistence unit using WAS data source triggers the observed behavior. This limitation will be corrected in the WAS EJB3 Feature Pack and future releases. Immediate solution is not to specify the non-jta-data-source in the persistence unit but replace with connection information using properties openjpa.ConnectionUserName openjpa.ConnectionPassword openjpa.ConnectionURL openjpa.ConnectionDriverName It is not the ideal solution, but functional. Albert Lee On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote
Re: WebSphere and transaction managers
This is known problem in WAS. The reason is data source created in WAS is always enlisted in the current global transaction, therefore RESOURCE_LOCAL persistence unit using WAS data source triggers the observed behavior. This limitation will be corrected in the WAS EJB3 Feature Pack and future releases. Immediate solution is not to specify the non-jta-data-source in the persistence unit but replace with connection information using properties openjpa.ConnectionUserName openjpa.ConnectionPassword openjpa.ConnectionURL openjpa.ConnectionDriverName It is not the ideal solution, but functional. Albert Lee On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, It looks like the new WebSphere transaction manager lookup code is missing some functionality available elsewhere. See OPENJPA-149 (https://issues.apache.org/jira/browse/OPENJPA-149) and OPENJPA-153 (https://issues.apache.org/jira/browse/OPENJPA-153) for details. The key problems are: OPENJPA-149: the WASManagedRuntime class throws exceptions on some methods, preventing OpenJPA from being able to suspend transactions OPENJPA-153: even when specifying a non-JTA data source, the data source returned does not allow commits. It does seem like the behavior of the data source is at least a bit different than the JTA data source, since OpenJPA is able to call setAutoCommit(). These seem like usability issues with WAS. I'm hoping that someone with more WAS knowledge than me can resolve the issues easily. Any takers? -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: WebSphere and transaction managers
From what the user said, it sounds like another solution is to use a different ManagedRuntime that allows suspension. My guess is that this is not an official IBM API, and is the reason that we're not using it. Is there some other official means by which we could change WASManagedRuntime to allow suspend etc.? In short, if we solve OPENJPA-149, then we have the easiest-of-all pathways covered, and OPENJPA-153 is less important. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: Albert Lee [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 11:21 AM To: open-jpa-dev@incubator.apache.org Subject: Re: WebSphere and transaction managers This is known problem in WAS. The reason is data source created in WAS is always enlisted in the current global transaction, therefore RESOURCE_LOCAL persistence unit using WAS data source triggers the observed behavior. This limitation will be corrected in the WAS EJB3 Feature Pack and future releases. Immediate solution is not to specify the non-jta-data-source in the persistence unit but replace with connection information using properties openjpa.ConnectionUserName openjpa.ConnectionPassword openjpa.ConnectionURL openjpa.ConnectionDriverName It is not the ideal solution, but functional. Albert Lee On 2/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: Hi, It looks like the new WebSphere transaction manager lookup code is missing some functionality available elsewhere. See OPENJPA-149 (https://issues.apache.org/jira/browse/OPENJPA-149) and OPENJPA-153 (https://issues.apache.org/jira/browse/OPENJPA-153) for details. The key problems are: OPENJPA-149: the WASManagedRuntime class throws exceptions on some methods, preventing OpenJPA from being able to suspend transactions OPENJPA-153: even when specifying a non-JTA data source, the data source returned does not allow commits. It does seem like the behavior of the data source is at least a bit different than the JTA data source, since OpenJPA is able to call setAutoCommit(). These seem like usability issues with WAS. I'm hoping that someone with more WAS knowledge than me can resolve the issues easily. Any takers? -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
