[GitHub] [activemq-artemis] funkyjive commented on pull request #4403: ARTEMIS-4205 Database Primitive Manager

["funkyjive (via GitHub)" <gi...@apache.org>]

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: gitbox-unsubscribe@activemq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org