"[X Module] is Being Written To": Understanding and Mitigating Write Lock Errors in PowerFab

Not version-specific

Tekla PowerFab Tekla PowerFab GO

Encountering the warning message "[X Module] is being written to [or read by] 'user' - unable to obtain write lock" within PowerFab can be disruptive to your workflow. This message indicates that the system is currently preventing your action to ensure data integrity. At its core, this is due to a mechanism called a "write lock." This article will delve into what write locks are, why they occur within PowerFab, and most importantly, provide you with practical steps to understand and mitigate these temporary blocking issues, allowing you to continue your work smoothly.

Note:

You might encounter this problem as MySQL error 1205, with the message "Lock wait timeout exceeded; try restarting transaction". It will likely appear in the error-log.log file.

See also:

Directory descriptions section of the Default directories product guide.

What Exactly is a "Write Lock" and Why Does PowerFab Use Them?

A "write lock" is a fundamental feature in database systems. Imagine a single-lane bridge: only one car can cross at a time to prevent accidents. Similarly, a write lock ensures that when one part of PowerFab is being actively modified (written to) by a user or a process, others are temporarily prevented from making changes to the same data.

This mechanism is crucial for several reasons:

Preventing Data Corruption: If multiple users were allowed to edit the same inventory information simultaneously, it could lead to inconsistencies and errors in your critical data. Write locks ensure that changes are applied in a controlled and sequential manner.
Ensuring Data Integrity: By preventing concurrent modifications, write locks guarantee that the data you see and rely on within PowerFab is accurate and reflects the latest committed changes.
Maintaining Transactional Consistency: Many actions in PowerFab involve multiple steps that need to be executed in a specific order. Write locks help maintain this consistency during these transactions.

While these locks are essential for data integrity, they can sometimes lead to the "[X Module] is being written to..." message if another process holds the lock for a period of time while you are trying to make changes.

Common Reasons for Write Lock Errors in PowerFab and What You Can Do

Software and Application-Related Causes

`_fs_rl_user` Activity

The `_fs_rl_user` is a dedicated service user used by PowerFab for various background tasks and integrations. If you see this user mentioned (though the error message could contain any user), it could indicate that:

API Integrations: Many third-party integrations (like CRM systems, barcoding or other business tools) connect to PowerFab through its Application Programming Interface (API). Transactions initiated by these integrations are often run under the _fs_rl_user account.
- What You Can Do: If the lock seems to be held by _fs_rl_user, it's likely due to an ongoing integration process. You may need to wait for the synchronization or data exchange to complete. If these locks are frequent and disruptive, consider reducing the interval at which the updates occur (especially if its initiated through an automated event)
Automated Inventory Export/Sync (e.g., ProNest): PowerFab might have scheduled automated events to export or synchronize inventory data with third-party systems like ProNest. These processes require exclusive write access to the inventory module.
- What You Can Do: If you suspect an automated sync is in progress, waiting for it to finish is usually the best course of action. If these synchronizations frequently cause issues, your PowerFab administrator might be able to adjust their schedules to minimize conflicts during peak usage hours.
Automated Data Gathering: PowerFab may have scheduled tasks to gather inventory, project, or production data for reporting or other internal purposes. These tasks can also temporarily lock relevant modules.
- What You Can Do: Similar to automated syncs, waiting for the data gathering process to complete is generally necessary. If these processes are causing significant delays, consult with your PowerFab administrator to understand their frequency and duration.

Importing into a Production Job

Importing data into a production job in PowerFab is a high-priority operation. When an import process is initiated, it takes precedence over all other changes to that specific job. This means that no other users will be able to make any modifications to the job data until the import is fully completed.

What You Can Do: If you initiate an import into a production job, ensure that you stay at your workstation and allow the import process to finish without interruption. Leaving your desk or switching to other tasks before the import is complete will hold the write lock and prevent other users from working on that job. Be mindful of this and communicate with your team if you need to perform a large import that might take some time.

Simultaneous User Edits

Simultaneous User Edits: It's also possible that another PowerFab user is simply trying to edit the exact same data you are trying to modify at the very same moment. This is a natural occurrence in multi-user systems.

What You Can Do: In this scenario, the "Try Again?" prompt is your immediate option. Usually, the other user's edit will be completed quickly, and you'll be able to proceed on your next attempt. If the issue persists, briefly communicating with your colleagues might reveal who is currently working on that specific data.

Hardware and Infrastructure-Related Causes

Slow Server Hardware

Older HDDs or under-resourced servers can lead to longer write lock durations.

What You Can Do: Report persistent issues to IT for server performance investigation and potential upgrades (SSDs, more RAM, more CPU cores assigned if VM).

Slow or Unstable Network Connection

Network latency or instability can delay the acquisition and release of locks, making them seem longer.

What You Can Do: Check your local connection, restart network equipment, and report persistent issues to IT for network troubleshooting. If you're working in the desktop application remotely, make sure you're utilizing Scenario 1: Work with a terminal server connection section of the Manage Tekla PowerFab remote work product guide.

Potential Configuration Changes

Before considering any configuration changes, please ensure you have carefully reviewed the "What You Can Do" advice provided in the "Common Reasons for Write Lock Errors in PowerFab and What You Can Do" section above. Implementing the suggested mitigations related to user behavior, data imports, and potential hardware/network issues can often resolve the majority of write lock occurrences without requiring server-level adjustments. Additionally, make sure you are on the latest version of MySQL that is packaged with the latest installer. See Update MySQL version for Tekla PowerFab. Once all of these have been considered and implemented, you can continue below.

If, after considering all possible causes and implementing the recommended actions, you are still experiencing frequent write lock errors, especially in a large organization with many concurrent users, you might consider adjusting the innodb_lock_wait_timeout setting in your MySQL configuration file (my.ini).

Understanding the innodb_lock_wait_timeout Setting:

The innodb_lock_wait_timeout setting in MySQL determines the maximum number of seconds (an integer value) that the InnoDB storage engine will wait for a row lock to be released before giving up and returning an error to the requesting transaction. In PowerFab's default configuration, this value is typically set to 20 seconds.

Considering an Increase:

In environments with a high volume of concurrent users or where certain necessary operations (like large imports or complex automated processes) might occasionally take slightly longer, temporarily increasing the innodb_lock_wait_timeout value in small increments could provide the system with a bit more time to resolve lock contention before reporting an error. For example, you might consider increasing it to 30 or 40 seconds.

Important Considerations and Cautions:

This is a Server-Level Change: Modifying the my.ini file requires server access and a restart of the MySQL service. These actions should only be performed by a qualified database administrator or your IT support team.
Increasing the Timeout Can Mask Underlying Issues: While increasing the timeout might reduce the frequency of "unable to obtain write lock" errors, it's crucial to ensure that the underlying causes (e.g., long-running queries, inefficient processes, hardware bottlenecks) are also being investigated and addressed. Simply increasing the timeout doesn't solve these root problems and could potentially lead to other performance issues if locks are held for excessively long periods.
Potential for Longer Blocking: While the intention is to allow more time for locks to clear, increasing the timeout also means that if a genuinely problematic lock occurs (e.g., due to a hung transaction), other processes might be blocked for a longer duration before an error is finally returned.
Increment Gradually: If you decide to adjust this setting, it's recommended to do so in small increments and monitor the system's behavior closely. Avoid making large jumps in the timeout value.
Consult with Experts: It is highly recommended to consult with your database administrator or Trimble support before making any changes to the innodb_lock_wait_timeout setting to ensure it's the appropriate solution for your specific environment and to understand the potential implications.

In summary, adjusting the innodb_lock_wait_timeout should be considered a last resort after thoroughly investigating and addressing the potential causes outlined earlier in this article.

Note:
You can save changes to the my.ini file at any time, but the changes will not take effect until the MySQL service has been stopped and started again.

Bug Fixes

There was a bug presented in 2024SP3, where if a user had transaction history opened while editing an inventory record, a read lock error could occur. To remedy this make sure you are on, at least, the latest service pack of your current version (2024 and above).