Versions available for this page: CUBRID 8.2.1 |
glo restore rules are mandatory as for other class instance. If a transaction is rolled back, any updates to glo (LOs and FBOs) are rolled back. When a transaction is committed, all updated glos are permanently stored.
If a database crashes during the execution of ROLLBACK WORK or COMMIT WORK statement, the restore procedures for glos are enforced when the database restarts. The restore procedures for LOs are performed internally by the database system when the database restarts. The restore procedures for FBO updates are completed next time the user who updated FBO when the system crashed reconnects to the database. Read and update locks on the glo are owned by the database until the restore is completed.
To support the FBO restore, the database uses the temporary shadow file for updates to FBOs. This means that the user who updates FBO must have update authorization on the directory in which FBO exists (in addition to enough space to create a working copy of FBO data). An update operation on FBO instance may fail if the user does not have write authorization on the directory where FBO is located. Likewise, an update operation may fail if the user does not have database authorization by the database to update instances of the glo classes or subclasses.