funkyjive commented on PR #4403:
URL:
https://github.com/apache/activemq-artemis/pull/4403#issuecomment-1605667258
@rvais Truth is I don't know if I really do agree with that. I coded an
implementation oriented around of the DistributedPrimitiveManager
specification using specialized database features.
I don't know that attempting to utilize those features and approaches inside
JdbcSharedStateManager ultimately does create something "simplified and
unified". Those underlying mechanisms are actually quite different from
anything in JdbcSharedStateManager. For instance, go look at any method in
JdbcSharedStateManager -- for instance "writeState" or "readState". The
entirety of the implementation is oriented around managing a transaction and
its state with the database. But none of that correlates with the database
specific features in my implementation -- there aren't any transactions, just
remote locks held in the database itself.
So to use JdbcSharedStateManager and utilize this other form of database
based locking it would have to be refactored and generalized. But to what end?
What would do we get out of it? If JdbcSharedStateManager already supports the
databases (Oracle,MSSQL, Postgres, MySQL), why even do it?
So if the consensus thinking is:
"We like the idea of a DatabasePrimitveManager but we think that the
implementation should utilize the existing JdbcSharedStateManager to achieve
that end", I can accept that. Fundamentally, I believe that Artemis *should*
be capable of having two brokers do high availability w/ replication (no need
for shared SAN) and still be able to avoid "split-brain" through utilization of
a database that is already available from the application. So however that can
be achieved.
I'm not going to do an implementation with JdbcSharedStateManager because my
needs have changed. I am not attempting to use replication anymore. I just
wanted to offer this concept I researched before I moved on.
From what I can tell, JdbcSharedStateManager is not exactly what is called
for in the DatabasePrimitiveManager spec because there is all kinds of other
state information in there ("Live", "Falling Back", "Paused"). I think it was
written with a different state and purpose in mind. You will likely have to do
some additional things to "fit it in" anyway. I could be wrong, but it doesn't
seem like it will be simpler to me -- but I don't have mastery on all the
thinking and background that went into the creation of JdbcSharedStateManager.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
