3.0 Enhancement? Concurrent initialization of cluster.state and cluster.lock.
High-Availability JDBC
Brought to you by:
ferraro
Menu
▾
▴
This is a side question. We briefly talked about slow HA-JDBC 3.0 startup in another thread, but I wanted to pull it out into a different thread on its own.
I mentioned I was seeing slower HA-JDBC start in 3.0 versus 2.0, because it has to create cluster.state and cluster.lock separately and consecutively now. I think you said it was unavoidable, and would be refactored in a future release.
I was thinking, though, is it possible to initialize cluster.state and cluster.lock concurrently? If so, it would hide the latency and timeouts of the second initialization, and distributed HA-JDBC/jGroups would start twice as fast in 3.0.
What do you think?
Last edit: Justin Cranford 2014-05-06
That's definitely a possibility.
I'm in the process of integrating FORK channels for 3.next. If the implementation turns out to simple enough, I can backport this to 3.0.x. This would enable the distributed state manager and distribute lock manager to share the same channel.