[FOLIO-3753] R/W Split Adjustment Created: 11/Apr/23  Updated: 30/Nov/23

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Epic Priority: P3
Reporter: Oleksii Petrenko Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to RMB-975 Define DB_HOST_ASYNC_READER, DB_PORT... Open
Epic Name: R/W Split Adjustment
Sprint:
Development Team: None

 Description   

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-oai-pmh should replace any retrieving 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)

Note: Some SELECT statements write and will fail when run readonly, for example SELECT nextval('mysequence')

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.


Generated at Thu Feb 08 23:30:26 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.