funkyjive commented on PR #4403:
URL:
https://github.com/apache/activemq-artemis/pull/4403#issuecomment-1591655010
Full disclosure, I don't know each detail about the inner functioning of the
JdbcSharedStateManager itself. So there may be things that I am missing.
But high level differences between the approach:
The JdbcSharedStateManager is written to utilize a locking mechanism more
closely to the JDBC Spec -- i.e. implement locking oriented around transactions
and stuff in the database server that can be done in a more common way between
database systems and providers. This involves record insertions and update
locks and stuff. There is infrastructure built up around this. My purpose is
not to detract from this implementation at all. There was thought and
complexity put into this implementation.
The implementation in this PR can be thought of more as a simple "pass
through" to database features offered by specific databases in a per-database
way. There is no JDBC specification correlation for the database features that
are used here, it is just that each of these databases happens to support an
"application locking" concept in its own specific way.
There is no table or row lock involved, instead each individual database
implementation provides a mechanism for acquiring a logical lock. Here is the
heart of it from each database:
Oracle: { ? = call dbms_lock.request( lockhandle => ?, lockmode =>
DBMS_LOCK.X_MODE, timeout => 0)}
MSSQL: {? = call sp_getapplock(@Resource=?, @LockMode='Exclusive',
@LockOwner='Session', @LockTimeout=0)}
MySQL: {? = call GET_LOCK(?, 0)}
Postgres: {? = call pg_try_advisory_lock(?) }
As you can see, these are all individual stored procedure concepts that
interact with special implementation on the database system itself. No
standardization or specification via JDBC except for that they are called
through the JDBC Callable interface for calling functions.
As you look and compare with the journal-sql.properties file from the the
JdbcSharedStateManager, you can see that while there does exist database
specialization of configuration via queries -- you can also see that there is a
logical construct created and maintained by the JdbcSharedStateManager and then
each database needs to be able to conform to that logical construct. And that
logical construct relies upon database artifact creation and manipulation (i.e.
tables and rows, etc).
If I was to make arguments for or against any particular approach, I could
argue that the implementation of JdbcSharedStateManager is more generic and has
the potential to be brought to more JDBC database types. It is based on
concepts that should generally be available within database supporting JDBC
drivers and should be potentially able to be ported to more things. I am fairly
certain that was front and center in mind during its design.
I can also argue that my implementation has a certain simplicity in that it
is essentially a pass-through mechanism to allow Artemis in Java to utilize a
clusterable mutex provided by the database -- which is exactly the concept
sought after in the pluggable quorum voting concept with the
DistributedPrimitiveManager base class.
I suspect that someone who knows JdbcSharedStateManager better than me could
utilize it to implement a DatabasePrimitiveManager that only interacted with
the database via JDBC specification calls and didn't use specific
implementation features.
--
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]
