Blog › ICP guides

Magic xpa developer on retainer: Task Modify mode record lock hold, Magic Software, uniPaaS developer on monthly retainer

October 8, 2026 · ~15 min read

A Magic xpa developer was maintaining a customer order management application built in Magic xpa Application Platform 3.2 for a mid-size wholesale distributor. The application managed the full order lifecycle and included an “Update Order Status” workflow that allowed operations supervisors to review pending orders, apply credit-terms validation, and transition approved orders from “Pending” to “Confirmed” status. The workflow was implemented as an Online task named OrderEntry.UpdateOrderStatus with Task Mode set to Modify on the Orders table. When a supervisor selected a pending order and the task opened in Modify mode, Magic xpa’s implicit transaction model acquired a database-level row lock on the selected order record through the SQL Server backend driver. The task’s Before-Field-Change event on the CreditTerms field contained the business-rule validation: if the new credit terms code exceeded the customer’s approved credit tier, the event handler raised an error message and called a Quit task action to exit the task and return to the calling browse program. The developer tested the validation logic against orders where all credit terms fell within approved tiers; in production, three orders had supervisors attempt to set credit terms above the approved tier, triggering the validation failure and the Quit task action. Magic xpa exited the task and returned to the calling program without issuing a Rollback transaction operation. SQL Server continued holding an exclusive row lock on each of the three order records for the remainder of the session. Other operators attempting to open those three orders in Modify mode received SQL Server lock-wait timeout errors after 30 seconds. Concurrent blocked sessions: 3 → 0 after adding a Rollback transaction operation on the failure branch before the Quit task action.

The root cause was a missing Rollback transaction operation on the Before-Field-Change failure branch. In Magic xpa’s implicit transaction model, a task that opens a table in Modify mode enters a transaction scope automatically: when the task navigates to a record and the task enters edit state, Magic xpa issues the appropriate database-level lock acquisition through its backend driver (for SQL Server: a SELECT ... WITH (UPDLOCK) hint or equivalent update-intent lock; for Oracle: SELECT ... FOR UPDATE; for DB2: SELECT ... FOR UPDATE WITH RS). This lock is acquired as part of the implicit transaction that Magic xpa manages for the task. The implicit transaction scope in Magic xpa is not simply “per record” — it spans the entire task execution from when the task enters edit state for a record until either a Commit transaction operation is executed (which writes the record changes and releases the lock) or a Rollback transaction operation is executed (which discards the buffered changes and releases the lock). A Quit task action in Magic xpa exits the current task’s event loop and returns control to the calling program or task. Quit task does not automatically issue a Rollback transaction: it is an abrupt exit from the task’s execution flow, leaving any open implicit transaction — and all database-level row locks it holds — intact on the backend database server. The lock persists until the Magic xpa session ends or until Rollback transaction is explicitly issued.

The interaction between Magic xpa’s event model and the implicit transaction scope is what makes this lock-hold pattern particularly hard to reproduce in development. Magic xpa tasks are structured around a hierarchical event model: the task has a Record Prefix event (fires before the task displays a record), Before-Field-Change and After-Field-Change events for individual fields (fire before or after a field value is changed by the user or by a task flow operation), a Record Suffix event (fires after all field-level operations complete), and task-level events (Task Prefix, Task Suffix). In a Modify mode task, the implicit transaction scope begins at the point when Magic xpa transitions the record to edit state — typically during or after the Record Prefix event when the task first navigates to a record in Modify mode. All field-level events, including Before-Field-Change, execute within this active transaction scope. A Quit task action issued from within a Before-Field-Change event exits the entire task event loop immediately, bypassing the Record Suffix event and any end-of-record cleanup that would normally call Rollback transaction. The developer who tested the validation logic did so by launching the task fresh for each test case; in each test, the task entered Modify mode, the developer made a field change, the Before-Field-Change event fired, and the task either committed (passing case) or was quit (failing case) — but after Quit, the test session ended as well, causing the implicit transaction to be rolled back by the session cleanup. In production, the session persisted across many task invocations; the three failed Quit task exits left three implicit transactions open with their row locks held for the duration of the long-running production session.

Magic xpa’s Application Server deployment model amplifies the lock-hold duration in web-deployed applications. In a Magic xpa Application Server deployment, the Magic xpa Runtime (engine) runs on the server, and users interact with the application through a browser via the Magic xpa Rich Internet Application (RIA) or HTML5 client. Each user’s interaction is managed as a Magic xpa session on the server. If a user closes their browser window without properly exiting the task (an abrupt disconnect, a network timeout, or a browser crash), the Magic xpa session may remain active on the server for the configured session timeout period — typically 30 to 60 minutes. During this entire period, any open implicit transaction from the last task the user was executing continues to hold its row locks on the backend database. Three orders locked for 45 minutes in a Magic xpa Application Server deployment is not unusual; three orders locked for the full session lifetime in a thick-client Magic xpa deployment (where the session persists from morning logon to evening logoff) is the common production scenario. A retainer developer auditing Magic xpa applications for lock-hold bugs must examine both the event-level failure branches (where Rollback transaction is missing before Quit task) and the session-level timeout configuration (Magic xpa Application Server timeout settings that control how long orphaned sessions are kept alive with their associated database locks).

Magic xpa Application Platform, the implicit transaction model, and Task Mode locking

Magic Software Enterprises developed the Magic 4GL in the mid-1980s as a metadata-driven application development platform. Unlike conventional programming languages where developers write procedural code, Magic 4GL (and its successors) uses a repository-based, declarative model: developers define tasks, programs, and data sources in the Magic Studio IDE by filling in properties tables rather than writing source code lines. The platform then generates and executes the application logic from the metadata. This approach produced compact applications that ran on a wide range of hardware and database backends, making Magic 4GL popular for building data-entry and reporting applications in manufacturing, distribution, and healthcare in the 1990s and early 2000s. Magic Software renamed the platform uniPaaS (Universal Platform as a Service) in 2009, emphasizing its ability to deploy the same application metadata to Windows client, web browser, and mobile form factors from a single development artifact. uniPaaS was renamed Magic xpa Application Platform in 2013, with continued releases through Magic xpa 3.x and 4.x.

The Magic xpa data model centers on tasks and data sources. A data source is a Magic xpa metadata definition of a database table (its columns, indexes, and backend connection). A task is the unit of program logic that operates on one or more data sources. Every task has a Task Mode property that determines how the task interacts with its main data source: Query mode (read-only, no locks), Browse mode (read-only with display), Modify mode (read-write, acquires update-intent locks), Create mode (insert-only, acquires insert locks), and Delete mode (delete-only). In Modify mode, Magic xpa enters a transaction scope for each record the task navigates to in edit state. The implicit transaction model means there is no explicit BEGIN TRANSACTION call in the Magic xpa application metadata — Magic xpa manages the transaction lifecycle on behalf of the developer. The developer calls Commit transaction (an explicit operation in the task flow) to write the buffered changes and release the lock, or Rollback transaction to discard the changes and release the lock. On the record-navigation level, Magic xpa automatically issues a Commit transaction when the user moves to the next record after successfully editing the current one; but when the task exits abnormally via Quit task (or when the session terminates unexpectedly), the implicit transaction may be left uncommitted.

The Magic xpa event system has four main event categories that interact with the implicit transaction scope: System events (fired by Magic xpa for standard operations like record navigation, field focus changes, and task open/close); User events (fired by explicit user interactions like button clicks); Timer events (fired on a schedule for background processing); and Expression events (conditional triggers based on field value evaluations). The Before-Field-Change and After-Field-Change events are system events that fire when a field’s value is changed while the task is in edit state within Modify mode. Since these events fire within the active implicit transaction, any Quit task action issued from within them exits the task without the transaction being committed or rolled back. The After-Record-Suffix event provides the natural point for end-of-record cleanup (including issuing Rollback transaction before Quit task on a validation failure), but many Magic xpa developers implement per-field validation in Before-Field-Change events for immediate user feedback and issue Quit task directly from there without reaching the Record Suffix stage. The fix for the OrderEntry.UpdateOrderStatus task was to add a Rollback transaction operation immediately before the Quit task operation in the Before-Field-Change event handler for the CreditTerms field. Concurrent blocked sessions: 3 → 0.

Magic xpa version history affects the specifics of how implicit transactions interact with the backend database driver. In Magic xpa 3.x and earlier, the transaction scope behavior for Modify mode tasks was governed by the task’s Transaction Mode property, which could be set to “Physical” (the implicit transaction is mapped directly to a database transaction: one DB transaction per task record) or “Logical” (Magic xpa manages the transaction scope itself, potentially batching multiple record operations into a single DB transaction). In Physical transaction mode, Rollback transaction issues a database-level ROLLBACK that releases all row locks acquired since the last BEGIN TRANSACTION. In Logical transaction mode, Magic xpa’s transaction manager controls when database-level commits and rollbacks occur, and calling Quit task without Rollback transaction may leave a Magic xpa logical transaction open even if a database-level transaction was already committed for an earlier record. Magic xpa 4.x introduced an updated transaction model with explicit transaction scoping controls. A retainer developer migrating a Magic xpa 3.x application to 4.x must audit all Quit task paths in Modify mode tasks to confirm that Rollback transaction is present before every Quit in both Physical and Logical transaction mode contexts.

Typical Magic xpa developer retainer work and what it looks like in a work log

Task Modify mode Quit without Rollback transaction on business-rule failure branches is the canonical Magic xpa invisible production lock. The pattern is consistent: an Online task opens a record in Modify mode; a Before-Field-Change or Record Suffix event handler applies a business-rule validation; on the failure branch, the handler issues an error message and calls Quit task to exit the task cleanly — but omits Rollback transaction before the Quit. The developer tests the validation with data where all cases pass; the Quit-without-Rollback path is only exercised in production when a real boundary condition is encountered. Three customer order records locked for the session lifetime; other operators blocked with SQL Server lock-wait timeouts after 30 seconds. Fix: Rollback transaction added on the failure branch in the Before-Field-Change event handler, immediately before the Quit task operation. Concurrent blocked sessions: 3 → 0. Work log: “OrderEntry.UpdateOrderStatus Before-Field-Change for CreditTerms: condition check CreditTerms > CustomerApprovedTier; error message raised; Quit task called without Rollback transaction; SQL Server UPDLOCK row lock held on 3 order records for session lifetime; concurrent blocked sessions: 3 → 0; fix: Rollback transaction added before Quit task on failure branch; 1.5h.”

Batch task Commit transaction missing at end of processing loop is the second most common Magic xpa retainer pattern. A Batch task in Modify mode that processes a set of records in a loop issues updates to each record within the task’s implicit transaction but does not call Commit transaction at the end of the loop iteration. In Magic xpa Physical transaction mode with a batch task, this means all row locks from all records processed in the batch are accumulated in a single database transaction that is not committed until the task ends normally. If the batch task processes hundreds of records before the normal end-of-task commit, hundreds of rows may be locked for the duration of the batch run. Concurrent batch tasks processing the same table will block on any row the first batch already holds. Work log: “Inventory.NightlyPriceUpdate batch task; Modify mode on INVENTORY table; 847 records processed; no Commit transaction within loop; all 847 rows held in single SQL Server transaction for 3-hour batch run; nightly reconciliation task blocked for 3h; fix: Commit transaction added after each 50-record batch within loop; max concurrent locked rows reduced from 847 to 50; reconciliation task unblocked; 2h.”

Magic xpa Application Server session timeout orphaned lock from browser disconnect is the third common Magic xpa retainer pattern. In Magic xpa Application Server deployments, a user who closes their browser tab or loses network connectivity without properly exiting the Magic xpa application leaves their server-side Magic xpa session running for the configured session timeout period. Any Modify mode task that was active at the time of the disconnect continues to hold its row locks on the backend database until the Magic xpa session expires. In a production environment with a 60-minute session timeout, a single disconnected session can block other users from accessing a set of records for an hour. The diagnosis requires checking the Magic xpa Application Server session log (the Magic xpa Application Server management console lists active sessions, their last activity time, and their current task context) to identify sessions that are past their last-activity threshold and still holding database locks (confirmed via SQL Server sys.dm_exec_requests or Oracle v$lock). Fix: reduce the Magic xpa Application Server session timeout for interactive applications to 5–10 minutes; add Rollback transaction in the Task Suffix event of all Modify mode tasks to ensure the transaction is cleanly closed before the session’s cleanup routine runs; and confirm that all Before-Field-Change and Record Suffix failure branches include Rollback transaction before any task-exit operation. Work log: “Magic xpa Application Server session timeout analysis; 3 active sessions past 55-minute last-activity threshold; SQL Server sys.dm_exec_requests shows 3 exclusive locks on ORDERS table rows; session IDs correlated to disconnected browser sessions (browser closed without logout); session timeout reduced from 60m to 8m; Rollback transaction added in Task Suffix event of all Modify mode tasks; orphaned lock duration reduced from 60m to 8m; 2.5h.”

How HourTab tracks Magic xpa developer retainer hours

Magic xpa Task Modify mode record lock-hold bugs are invisible by the same mechanism that makes them hard to reproduce in development: the Magic xpa application raises an error message and exits the task cleanly; no Magic xpa runtime error is logged; no SQL Server error is raised when the lock is granted; the supervisor’s session continues normally after the Quit task returns them to the calling browse program. The only evidence of the problem is on a different workstation: an operator attempts to open one of the three locked order records in Modify mode and receives a SQL Server lock-wait timeout after 30 seconds. Connecting the lock-wait timeout on workstation B to the open implicit transaction from the failed validation on workstation A requires either querying SQL Server’s sys.dm_exec_requests and sys.dm_os_waiting_tasks dynamic management views to identify which session holds the exclusive lock on the ORDERS table rows, or reviewing the Magic xpa task event flow for every Modify mode task that accesses the ORDERS table to find all Quit task actions that are not preceded by Rollback transaction on every failure path.

The work log must name the mechanism to be auditable: which Magic xpa task and event handler (OrderEntry.UpdateOrderStatus, Before-Field-Change for CreditTerms), the business-rule condition that triggered the failure branch (new credit terms code exceeded customer approved tier), the Quit task action that was issued without Rollback transaction, the database lock that was held (SQL Server exclusive row lock via UPDLOCK on 3 ORDER records), the concurrent blocked-session count before and after the fix (3 → 0), the fix (Rollback transaction added before Quit task on the failure branch), and the verification (tested credit-terms violation scenario with two Magic xpa sessions simultaneously; second session no longer receives SQL Server lock-wait timeout after first session hits the validation failure branch and Quit task is executed). A log entry that says “fixed record lock issue in order status task, 1.5h” is not auditable. A log entry that names OrderEntry.UpdateOrderStatus, the Before-Field-Change event for CreditTerms, the Quit-task-without-Rollback exit path, the 3 locked ORDER records, and the Rollback-before-Quit fix is auditable and defensible to the wholesale distributor client. HourTab gives Magic xpa developers a public retainer-hours URL they send to clients — wholesale distributors, manufacturers, healthcare providers, and logistics companies that built Magic xpa, uniPaaS, or Magic 4GL applications in the 1990s, 2000s, and 2010s for order management, inventory control, logistics routing, and patient record management, maintained today by the original Magic developer or a successor retainer consultant.

Comparative context: Magic xpa Task Modify mode implicit transaction lock-hold bugs are structurally similar to transaction-scope lock-hold patterns in other 4GL environments where the platform manages transaction boundaries on behalf of the developer. Genero BDL retainers cover the FOR EACH UPDATE without COMMIT WORK pattern in Four Js Genero where Informix exclusive row locks accumulate in an open transaction when a batch function returns without calling COMMIT WORK. Uniface retainers cover the RETRIEVE-without-DISCARD pattern in Compuware Uniface where the TCC driver layer holds database-level row locks for all records retrieved with modification intent until store or discard is explicitly called. Gupta SQLWindows retainers cover the SqlPrepare FOR UPDATE cursor lock-hold pattern where the SQLWindows cursor model holds SQL Server update-intent row locks on the class-level SqlHandle until SqlEndFetch is explicitly called.

FAQ: Magic xpa developer retainers