You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
gnosygnu_xowa/400_xowa/src/gplx/xowa/mediawiki/includes/dao/XomwIDBAccessObject.java

69 lines
3.4 KiB

/*
XOWA: the XOWA Offline Wiki Application
Copyright (C) 2012-2020 gnosygnu@gmail.com
XOWA is licensed under the terms of the General Public License (GPL) Version 3,
or alternatively under the terms of the Apache License Version 2.0.
You may use XOWA according to either of these licenses as is most appropriate
for your project on a case-by-case basis.
The terms of each license can be found in the source code repository:
GPLv3 License: https://github.com/gnosygnu/xowa/blob/master/LICENSE-GPLv3.txt
Apache License: https://github.com/gnosygnu/xowa/blob/master/LICENSE-APACHE2.txt
*/
package gplx.xowa.mediawiki.includes.dao;
/**
* Interface for database access objects.
*
* Classes using this support a set of constants in a bitfield argument to their data loading
* functions. In general, objects should assume READ_NORMAL if no flags are explicitly given,
* though certain objects may assume READ_LATEST for common use case or legacy reasons.
*
* There are four types of reads:
* - READ_NORMAL : Potentially cached read of data (e.g. from a replica DB or stale replica)
* - READ_LATEST : Up-to-date read as of transaction start (e.g. from master or a quorum read)
* - READ_LOCKING : Up-to-date read as of now, that locks (shared) the records
* - READ_EXCLUSIVE : Up-to-date read as of now, that locks (exclusive) the records
* All record locks persist for the duration of the transaction.
*
* A special constant READ_LATEST_IMMUTABLE can be used for fetching append-only data. Such
* data is either (a) on a replica DB and up-to-date or (b) not yet there, but on the master/quorum.
* Because the data is append-only, it can never be stale on a replica DB if present.
*
* Callers should use READ_NORMAL (or pass in no flags) unless the read determines a write.
* In theory, such cases may require READ_LOCKING, though to avoid contention, READ_LATEST is
* often good enough. If UPDATE race condition checks are required on a row and expensive code
* must run after the row is fetched to determine the UPDATE, it may help to do something like:
* - a) Start transaction
* - b) Read the current row with READ_LATEST
* - c) Determine the new row (expensive, so we don't want to hold locks now)
* - d) Re-read the current row with READ_LOCKING; if it changed then bail out
* - e) otherwise, do the updates
* - f) Commit transaction
*
* @since 1.20
*/
public interface XomwIDBAccessObject {
/** Constants for object loading bitfield flags (higher => higher QoS) */
/** @var int Read from a replica DB/non-quorum */
public static int READ_NORMAL = 0;
/** @var int Read from the master/quorum */
public static int READ_LATEST = 1;
/* @var int Read from the master/quorum and lock out other writers */
public static int READ_LOCKING = READ_LATEST | 2; // READ_LATEST (1) and "LOCK IN SHARE MODE" (2)
/** @var int Read from the master/quorum and lock out other writers and locking readers */
public static int READ_EXCLUSIVE = READ_LOCKING | 4; // READ_LOCKING (3) and "FOR UPDATE" (4)
/** @var int Read from a replica DB or without a quorum, using the master/quorum on miss */
public static int READ_LATEST_IMMUTABLE = 8;
// Convenience constant for tracking how data was loaded (higher => higher QoS)
public static int READ_NONE = -1; // not loaded yet (or the object was cleared)
}