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. > > > >
