JDK 9 EA Build 155 is available on java.net
by Rory O'Donnell
Hi Galder,
*JDK 9 Early Access* b155 <https://jdk9.java.net/download/> is
available on java.net
There have been a number of fixes to bugs reported by Open Source
projects since the last availability email :
* b155 - JDK-8167273 : Calendar.getDisplayNames inconsistent with
DateFormatSymbols
* b154 - JDK-8157611 : field visiblePackages is null for the unnamed
module producing NPE when accessed
* b153 - JDK-8163449 : Allow per protocol setting for URLConnection
defaultUseCaches
* b152 - JDK-8172158 : Annotation processor not run with -source <= 8
Dalibor and I are presenting at FOSDEM this weekend, we would love to
meet you there!
* JDK 9 Outreach - The Awesome Parts
<https://fosdem.org/2017/schedule/event/outreach/>
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
7 years, 9 months
REPL async semantics in the context of Hibernate 2LC
by Galder Zamarreño
Hi all,
Forgive me if we've discussed this before (I vaguely remember...), but the current async semantics always through me off a bit, let me explain:
I've been working on/off on Hibernate 2LC tutorial that demonstrates how to run 2LC on embedded, Wildfly and Spring set ups, and for each of them, explains how it all works in local vs clustered mode.
One of the sections involves working with queries, updating an entity that's part of the query, and seeing how that query gets re-executed from the db. When an entity is updated, that entity's update timestamp gets updated in a cache, which in a cluster environment is configured with repl async.
If you have two nodes A and B, it was expected that if you updated the entity in node A, you'd want to wait a tiny bit to run the query in node B so that the timestamp update would propagate to node B.
However, recent async semantics work in such way that if you updated the entity in node A and wanted to execute the query in node A, you still might want to add a little delay...
The reason for that is that the logic changes based on whether the ownership of entity type key in the update timestamp cache is in node A or node B. If the owner is node A, the cache is updated directly by the main thread. So you can execute a query on node A immediately after the update and it'll be fine.
However, if the owner is node B, even if the update was done in node A, node A will only be updated asynchronously. So, if after calling an update on node A, you do a query on node A, in this scenario you'd get outdated results for a small period of time. [1]
So, my question here is: can we do anything to make this more predictable from a users perspective? Or is it just not worth doing it? Or is it just a side effect that we must be aware off?
Cheers,
[1] https://gist.github.com/galderz/676f689884969658b01a7695f08dd7a2
--
Galder Zamarreño
Infinispan, Red Hat
7 years, 9 months
