Re: Pending patches

d be great (feel free to >> > apply the patch or I can do it after). >> > >> > note: some of the patches are waiting for some feedback - in >> > particular txmgr one, wonder about tomee usage which can >> > need to remove the private constructor of the

[jira] [Updated] (GERONIMO-6805) Use a time SPI abstraction to provide time to the transaction manager

[ https://issues.apache.org/jira/browse/GERONIMO-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florent Guillaume updated GERONIMO-6805: Patch Info: Patch Available > Use a time SPI abstraction to provide t

[jira] [Created] (GERONIMO-6805) Use a time SPI abstraction to provide time to the transaction manager

Florent Guillaume created GERONIMO-6805: --- Summary: Use a time SPI abstraction to provide time to the transaction manager Key: GERONIMO-6805 URL: https://issues.apache.org/jira/browse/GERONIMO-6805

[transaction] use Clock to manage time

2021, at 8:53 PM, Jean-Baptiste Onofre >> wrote: >> >> Hi Florent, >> >> Maybe we can start with a set of Jira or discussion on the mailing list. >> >> I think it makes sense to move forward on geronimo-transaction and >> prepare a new release. >> &

Modernizing geronimo-transaction

of a java.time.Clock for time measurement and timeout management, in order to allow better (and faster) unit testing. Thanks, Florent -- [image: Nuxeo Logo] <https://www.nuxeo.com/> Florent Guillaume Head of R [image: LinkedIn] <https://www.linkedin.com/in/fguillaume/> [image: Twitter] <http

connector/txmanager enlistment failure

ResourceException for instance (as is the case for other error cases). Thanks, Florent -- Florent Guillaume, Director of RD, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87

txmanager last resource commit optimization

in the list depends on a number of factors. Arjuna for instance implements this optimization, but only for resources that implement a custom marker interface. Thanks, Florent -- Florent Guillaume, Director of RD, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http

[jira] [Updated] (GERONIMO-6051) Transaction timeout detection

[ https://issues.apache.org/jira/browse/GERONIMO-6051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florent Guillaume updated GERONIMO-6051: Description: When a transaction is in timeout, the application can only know

[jira] [Commented] (GERONIMO-6051) Transaction timeout detection

[ https://issues.apache.org/jira/browse/GERONIMO-6051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13061372#comment-13061372 ] Florent Guillaume commented on GERONIMO-6051: - BTW this affects 3.1 also

[jira] [Created] (GERONIMO-6051) Transaction timeout detection

) Components: transaction manager Affects Versions: 3.0.1 Reporter: Florent Guillaume Priority: Minor When a transaction is in timeout, the application can only know about it when calling {{commit()}}. Wouldn't it make sense to make {{TransactionImpl.getStatus()}} do

Re: txmanager: shouldn't connection be removed from pool if it fails to enlist?

or disappears midway through a commit.  (The changes aren't going into 2.1.x since they involve an incompatible api change). thanks david jencks On Mar 11, 2011, at 7:17 AM, Florent Guillaume wrote: Hi David, all, I have the following situation using txmanager (2.1.3) as a standalone component

[jira] Created: (GERONIMO-5870) Remove connection from pool if it fails to enlist

(Regular issues) Components: connector Affects Versions: 2.1.3 Reporter: Florent Guillaume Priority: Minor When a connection fails to enlist, it should be removed from its pool. Consider the following: ConnectionFactory.getConnection

[jira] Updated: (GERONIMO-5870) Remove connection from pool if it fails to enlist

[ https://issues.apache.org/jira/browse/GERONIMO-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florent Guillaume updated GERONIMO-5870: Attachment: GERONIMO-5870.2.1.4.diff Patch for 2.1.4. Remove connection from

[jira] Updated: (GERONIMO-5870) Remove connection from pool if it fails to enlist

[ https://issues.apache.org/jira/browse/GERONIMO-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florent Guillaume updated GERONIMO-5870: Attachment: GERONIMO-5870.3.1.diff Patch for 3.1 Remove connection from pool

Re: txmanager: shouldn't connection be removed from pool if it fails to enlist?

https://issues.apache.org/jira/browse/GERONIMO-5870 On Wed, Mar 16, 2011 at 2:10 PM, Florent Guillaume f...@nuxeo.com wrote: I'll try to write a patch when I find the time. In the meantime I've made my XAResource more robust to know how to reset its state when there's a problem. I've tried

txmanager: shouldn't connection be removed from pool if it fails to enlist?

ticket and a patch if needed. Florent -- Florent Guillaume, Director of RD, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87

[jira] Created: (GERONIMO-5742) NPE in MultiPoolConnectionInterceptor.returnConnection with non-zero minPoolSize

: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector Reporter: Florent Guillaume Attachments: patch.diff There's a NPE in MultiPoolConnectionInterceptor.returnConnection when a non-zero minPoolSize is used

[jira] Updated: (GERONIMO-5742) NPE in MultiPoolConnectionInterceptor.returnConnection with non-zero minPoolSize

[ https://issues.apache.org/jira/browse/GERONIMO-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florent Guillaume updated GERONIMO-5742: Attachment: patch.diff NPE in MultiPoolConnectionInterceptor.returnConnection