|
1182 | 1182 | **Using the with-statement syntax for managing transactions is strongly |
1183 | 1183 | recommended.** By using the transaction's context manager, it allows for Python |
1184 | 1184 | exceptions to be properly treated as fatal to the transaction as when an |
1185 | | -exception of any kind occurs within a transaction block, it is unlikely that |
| 1185 | +uncaught exception of any kind occurs within the block, it is unlikely that |
1186 | 1186 | the state of the transaction can be trusted. Additionally, the ``__exit__`` |
1187 | 1187 | method provides a safe-guard against invalid commits. This can occur if a |
1188 | 1188 | database error is inappropriately caught within a block without being raised. |
|
1191 | 1191 | instruction methods provided by `postgresql.api.Transaction` objects. |
1192 | 1192 |
|
1193 | 1193 |
|
| 1194 | +Transaction Configuration |
| 1195 | +------------------------- |
| 1196 | +
|
| 1197 | +Keyword arguments given to ``xact()`` provide the means for configuring the |
| 1198 | +properties of the transaction. Only three points of configuration are available: |
| 1199 | +
|
| 1200 | + ``gid`` |
| 1201 | + The global identifier to use. Identifies the transaction as using two-phase |
| 1202 | + commit. The ``prepare()`` method *must* be called prior to ``commit()`` or |
| 1203 | + ``__exit__()``. |
| 1204 | +
|
| 1205 | + ``isolation`` |
| 1206 | + The isolation level of the transaction. This must be a string. It will be |
| 1207 | + interpolated directly into the START TRANSACTION statement. Normally, |
| 1208 | + 'SERIALIZABLE' or 'READ COMMITTED': |
| 1209 | +
|
| 1210 | + >>> with db.xact(isolation = 'SERIALIZABLE'): |
| 1211 | + ... ... |
| 1212 | +
|
| 1213 | + ``mode`` |
| 1214 | + A string, 'READ ONLY' or 'READ WRITE'. States the mutability of stored |
| 1215 | + information in the database. Like ``isolation``, this is interpolated |
| 1216 | + directly into the START TRANSACTION string. |
| 1217 | +
|
| 1218 | +The specification of any of these transaction properties imply that the transaction |
| 1219 | +is a block. Savepoints do not take configuration, so if a transaction identified |
| 1220 | +as a block is started while another block is running, an exception will be |
| 1221 | +raised. |
| 1222 | +
|
| 1223 | +
|
1194 | 1224 | Transaction Interface Points |
1195 | 1225 | ---------------------------- |
1196 | 1226 |
|
|
1269 | 1299 | property on the raised exception. |
1270 | 1300 |
|
1271 | 1301 |
|
1272 | | -Transaction Configuration |
1273 | | -------------------------- |
1274 | | -
|
1275 | | -Keyword arguments given to ``xact()`` provide the means for configuring the |
1276 | | -properties of the transaction. Only three points of configuration are available: |
1277 | | -
|
1278 | | - ``gid`` |
1279 | | - The global identifier to use. Identifies the transaction as using two-phase |
1280 | | - commit. The ``prepare()`` method *must* be called prior to ``commit()`` or |
1281 | | - ``__exit__()``. |
1282 | | -
|
1283 | | - ``isolation`` |
1284 | | - The isolation level of the transaction. This must be a string. It will be |
1285 | | - interpolated directly into the START TRANSACTION statement. Normally, |
1286 | | - 'SERIALIZABLE' or 'READ COMMITTED'. |
1287 | | -
|
1288 | | - ``mode`` |
1289 | | - A string, 'READ ONLY' or 'READ WRITE'. States the mutability of stored |
1290 | | - information in the database. Like ``isolation``, this is interpolated |
1291 | | - directly into the START TRANSACTION string. |
1292 | | -
|
1293 | | -The specification of any of these transaction properties imply that the transaction |
1294 | | -is a block. Savepoints do not take configuration, so if a transaction identified |
1295 | | -as a block is started while another block is running, an exception will be |
1296 | | -raised. |
1297 | | -
|
1298 | | -
|
1299 | 1302 | Prepared Transactions |
1300 | 1303 | --------------------- |
1301 | 1304 |
|
|
0 commit comments