Done
Details
Assignee
Roman BarannykRoman BarannykReporter
Martin TranMartin TranLabels
Priority
P3Story Points
2Sprint
NoneDevelopment Team
VegaFix versions
Release
Poppy (R2 2023)TestRail: Cases
Open TestRail: CasesTestRail: Runs
Open TestRail: Runs
Details
Details
Assignee
Roman Barannyk
Roman BarannykReporter
Martin Tran
Martin TranLabels
Priority
Story Points
2
Sprint
None
Development Team
Vega
Fix versions
Release
Poppy (R2 2023)
TestRail: Cases
Open TestRail: Cases
TestRail: Runs
Open TestRail: Runs
Created September 23, 2022 at 10:56 PM
Updated October 12, 2023 at 3:22 PM
Resolved June 29, 2023 at 2:37 PM
RMB-348 introduces the ability to direct the read and write calls to the respective database node, the reader or writer (if the database is configured in such a way). The separation of read and write queries brings performance improvements and scalability as the write node is freed up to do more writing while the read node is busy making retrievals. Most of the read-only code in RMB has already been updated to communicate to the Read node directly. However, there are many other public RMB APIs that are used for both reading and writing by RMB's clients that have not been updated to exclusively talk to the read node. To take advantage of the read/write split, mod-circulation-storage should replace any readonly code that calls the existing RMB "read" methods (which unfortunately could handle both read and writes) with one of the new RMB read-only methods that exclusively communicates to the read node. The table below shows the current RMB "read" methods that could handle reading and writing, and the new methods to replace them.
Existing Read APIs (that could handle writing as well)
Replace with the Readonly Counterpart
public void select(String sql, int queryTimeout, Handler<AsyncResult<RowSet<Row>>> replyHandler)
public void selectRead(String sql, int queryTimeout, Handler<AsyncResult<RowSet<Row>>> replyHandler)
public void select(String sql, Tuple params, Handler<AsyncResult<RowSet<Row>>> replyHandler)
public void selectRead(String sql, Tuple params, Handler<AsyncResult<RowSet<Row>>> replyHandler)
public void selectSingle(String sql, Handler<AsyncResult<Row>> replyHandler
public void selectSingleRead(String sql, Handler<AsyncResult<Row>> replyHandler)
public void selectSingle(String sql, Tuple params, Handler<AsyncResult<Row>> replyHandler)
public void selectSingleRead(String sql, Tuple params, Handler<AsyncResult<Row>> replyHandler)
public Future<Void> selectStream(String sql, Tuple params, int chunkSize, Handler<RowStream<Row>> rowStreamHandler)
public Future<Void> selectReadStream(String sql, Tuple params, int chunkSize, Handler<RowStream<Row>> rowStreamHandler)
public <T> Future<T> withTrans(Function<Conn, Future<T>> function)
public <T> Future<T> withReadTrans(Function<Conn, Future<T>> function)
void getSQLConnection(int queryTimeout, Handler<AsyncResult<SQLConnection>> handler)
void getSQLReadConnection(int queryTimeout, Handler<AsyncResult<SQLConnection>> handler)
public Future<PgConnection> getConnection() {
public Future<PgConnection> getReadConnection()
public void getConnection(Handler<AsyncResult<PgConnection>> replyHandler)
public void getReadConnection(Handler<AsyncResult<PgConnection>> replyHandler)
If the database cluster does not have a reader node, then calling these readonly methods will result in going to the same write node. The high level workflow will behave the same way as it does now before making these changes. See RMB's Readme for more configuration details.