Hi All, Thanks for your comments. Lovely to see that there's still interest in geronimo-transaction.
As an example to start the discussion, and because I find that showing code is in this case clearer, here's an example PR of what could be done using a Clock. https://github.com/apache/geronimo-txmanager/pull/5 You'll note that I updated the timeout test, which used to take 15s because of the sleeps, but is now instantaneous (that's the point of this change). The overhead of using clock.millis() over System.currentTimeMillis() is negligible in the default case, because when the clock is the one returned by Clock.systemUTC() then clock.millis() is just a one-method indirection to the same System.currentTimeMillis(), which will probably get inlined by the JIT anyway. I removed TransactionTimer instead of trying to reuse it because its getCurrentTime() method was static, so not amenable to subclassing in tests, and because Clock is already a perfect lightweight time abstraction -- provided we're ok with requiring Java 8 of course. Florent On Fri, Feb 12, 2021 at 8:53 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Hi, > > Using Clock will likely be slower than using System.nanoTime() as of today > but I assume you want something like > https://rmannibucau.metawerx.net/post/cdi-mock-java-clock. > We can surely add a TimeProvider {long now()} or so API we can set in our > transaction manager and have a default fast impl and a customizable impl > for tests using clock or so. > We can also drop the thread measuring the time since, as of today, it is > not really faster than using currentTimeMillis or other alternatives, we > just need to avoid Clock and Instant overhead by default but let them be > pluggable. > My question would be: is it about timeouts and sufficient for your testing > use case? > > @David Jencks <david.a.jen...@gmail.com> aout the logger, we already have > TransactionLog abstraction so I guess we can change it quite easily without > much code change so can open the door to experimentations. > > Something I spoke about some years ago (don't recall it was on our slack > or IRC) was to make it reactive and drop this thread local requirement. > Technically there is no reason to have it except some EE assumptions but in > modern code and with CompletionStages it is quite irrelevant so can be > another option for our future. > > But overall: yes the project is alive, just insanely stable so does not > move much ;). > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le ven. 12 févr. 2021 à 06:53, David Jencks <david.a.jen...@gmail.com> a > écrit : > >> Something I’ve wondered about since SSD drives became available… >> >> When implementing this using HOWL logger, the idea I had was to try to >> queue up stuff in the transaction log and release the transactions when the >> disk spun around and claimed to have written the bits onto rust. IIRC >> there’s a 10 ms time somewhere, which I thought was the time taken to >> actually write something. I could never find out for sure if the code >> actually worked and succeeded in defeating the hard drive’s built in >> caching. >> >> Now that SSDs are common, I wonder if a completely different logger >> implementation would be reasonable. (I haven’t looked at the code in >> years, but haven’t noticed any changes go by on the mailing list). >> >> David Jencks >> >> On Feb 11, 2021, at 8:53 PM, Jean-Baptiste Onofre <j...@nanthrax.net> >> 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. >> >> Thanks ! >> Regards >> JB >> >> Le 11 févr. 2021 à 22:50, Florent Guillaume <fguilla...@nuxeo.com> a >> écrit : >> >> Hi, >> >> Is there any interest in modernizing geronimo-transaction a bit? Is there >> any chance of then doing a release in the not too distant future if some >> patches get accepted (i.e., is geronimo-transaction completely dead or not)? >> >> FYI my first changes would probably be to allow usage 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&D [image: LinkedIn] >> <https://www.linkedin.com/in/fguillaume/> [image: Twitter] >> <https://twitter.com/efge> [image: Github] <https://github.com/efge> >> >> Nuxeo Content Services Platform. Stay ahead. >> >> >> >> -- [image: Nuxeo Logo] <https://www.nuxeo.com/> Florent Guillaume Head of R&D [image: LinkedIn] <https://www.linkedin.com/in/fguillaume/> [image: Twitter] <https://twitter.com/efge> [image: Github] <https://github.com/efge> Nuxeo Content Services Platform. Stay ahead.
