![]() Merge Refresh Workspace "LIVE" Workspace "PLAN 1" Workspace "PLAN 2"įig. Not visible until been "pulled in" with a refresh operation. Parent workspace changes after the child workspace has been created. In addition, Workspace Manager provides the "Refresh" operation that is important when the data in the Workspace is being merged, all changes get visible in the parent (here: LIVE) workspace. Even if a workspace manager transaction contains hundredths or thousands of committedĭML statements, it can be rolled back as a whole. On version-enabled tables are only visible in the current workspace, even after a COMMIT has been executed.Īnother database session, which is switched to LIVE or another workspace, cannot see the changes.Īt the end of a workspace manager transaction, changes are either merged into the parent workspace ![]() 1: two workspaces are being created as children of "LIVE" - we have one hierarchy levelĪ database session can switch to one of the workspaces and execute SQL commands. PLAN_1 child of LIVE PLAN_2 child of LIVE Workspace "LIVE" Workspace "PLAN 1" Workspace "PLAN 2"įig. When no workspacesĪre being created at all, the database will behave as without workspace manager. Things simple, in this document we will create all workspaces as children of LIVE. A new workspace is being created asĪ child of the current workspace so workspaces are organized as a hierarchy. Is the LIVE workspace, in which every database session starts. Workspaces in Oracle Workspace Manager are being organized hierarchically. changes within a workspace are only visible within that workspace.changes within one Workspace Manager transaction can be committed or rolled back as a whole.DML statements can come from an ApplicationĮxpress application, from a SQL client or from any other application. modify table data with SQL DML commands from multiple database sessions over a longer period of time.ĭatabase transactions are being committed as usual.Logical containers for long running transactions. Refers to Workspace Manager Workspaces, which are The Oracle Database contains a feature this "long running transactions" requirement since Time long running transaction (simulation) COMMIT / ROLLBACK (as a whole) COMMIT COMMIT Database session 1 Database session 2 COMMIT Database session 2 COMMIT We have transactions in the Oracle database since its early days, but these are restricted to the veryĭatabase session and therefore also to one user this is, as seen, totally different to a long running transaction. At the end, all changes of that transactions are being applied or rejected as a whole. Such scenarios require "long running transactions" Ĭhanges are being made to tables from within multiple database sessions, over a longer period of time even fromĭifferent users. In business applications, there is often the requirement to "play" with data, to simulateīusiness scenarios or to maintain multiple versions of data. Oracle Workspace Manager and Application Express Versioning or simulations with table data:
0 Comments
Leave a Reply. |