Data lock control mode = Automatic and managed: error deleting DB objects

Hello,
I'm experimenting with converting an existing configuration (Ordinary application) from an Automatic data lock control mode to managed to gain performance in multi-user use case.

I changed the configuration parameter "Data lock control mode" to "Automatic and managed" and converted several documents (with required registers, catalogs) to use the managed mode.

Almost everything works as expected: I can successfully post documents, undo document posting, mark for deletion, data locking works as expected, etc.

However, I cannot delete any converted and marked for deletion objects (documents, catalogs):
Lock manager use error
Automatic lock mode is not allowed in this transaction.

I tried to use this configuration in file mode, server-client mode, tried to debug it, but was unable to identify the problem.

Even this fails in the existing configuration:
1. Create a new Catalog "Catalog1" without any attributes and with managed data lock control mode.
2. Run configuration, add a new "Catalog1" item, mark it for deletion.
3. Run "Delete Marked Objects" and try to delete it.
4. Deletion fails with an error above.

However, if I create a new minimal configuration, I can't reproduce this error.

What am I missing?

1C:Enterprise has three different data lock control modes on the configuration level: Automatic, Managed and mixed (“Automatic and Managed”) mode. First two of them override any lock mode settings made on the objects level. In other words if you set the configuration lock mode into Automatic or into Managed mode, this setting will take effect on entire configuration regardless of object lock mode settings. In this case any transaction started at runtime will be correspondently Automatic or Managed.

When you set the configuration into the mixed lock mode you delegate the transaction lock mode choice down to the object level. In this case any implicit transaction started by the platform for object data change will have the mode setting derived from the object lock mode. Therefore, different objects can operate with different lock modes depending on their own settings. This mode is designed to give you an opportunity to gradually – one object after another – convert your application from Automatic into Managed lock mode.

The tricky part of this is that sometimes (quite often, actually) you change one object data during the process of changing another object data and the platform needs to choose an appropriate lock mode for the operation as a whole. For example you write the document which writes the register. What if the register has a different lock mode setting than the document?

When the first object in row requires the Automatic mode platform uses it for all objects changing in that transaction. It’s a simple case because the Automatic mode is more secure in terms of data consistency than the Managed lock mode which requires an adequate explicit lock setting in some cases (before a balance check, for instance).

The issue you wrote about arises when the first object in row requires the Managed lock mode but some objects requiring the Automatic mode are changing in the same transaction. Most probably you converted the document into Managed lock mode but don’t do the same thing with all registers the document writes. The platform considers it to be a threat for data integrity because you forget to convert the register into Managed lock mode and therefore, probably, also forget to add necessary explicit lock into those registers code (to protect its balance from been changed until the end of your transaction, for example).

So you can just switch into the Managed lock mode all registers been writing by the document and the error will disappear. But I suggest you try to switch the entire configuration into the Managed lock mode at once, without using mixed mode at all. Whatever you choose you will also need to protect the critical reading operations with explicit locks (for Managed objects in the first case and for all objects in the second).

I understand the difference between the three data lock control modes.

Is there any way (server logging?) to tell what configuration/database object causes the "Lock manager use error"? This way it would be easy to fix the problem.

Not exactly. As I mentioned in my first post, the deletion problem occurs even for newly created catalogs. It seems that they somehow implicitly interact with other configuration objects.

I've done that for the converted documents, however, it doesn't help, something else prevents the deletion.

It would be preferable, however, the configuration is quite large and changes quite often. We simply don't have required resources to switch the entire configuration into the Managed lock mode at once.

“Is there any way (server logging?) to tell what configuration/database object causes the "Lock manager use error"? This way it would be easy to fix the problem. “

The simplest way is to trace the source code with debugger to find out what code string causes the error. Most probably the string will point at some particular object which needs to be converted into Managed lock mode.

“The deletion problem occurs even for newly created catalogs. It seems that they somehow implicitly interact with other configuration objects.”

No, the platform is not supposed to work that way. Could you send me your configuration in order for me to reproduce and analyze the issue?

Unfortunately this does not help. I put a breakpoint on Obj.Delete(), then press F11 and immediately get the error.

At first I'll try the server logging with the following events that look promising: QERR, SDBL, TDEADLOCK, TTIMEOUT, TLOCK. If that fails to give any clues, I'll try to minimize our configuration to further isolate the issue and send it to you.

“I put a breakpoint on Obj.Delete(),”

What the “Obj” is? Document? Catalog item?

“I'll try the server logging”

I would like you to collect EXCP and TLOCK events and send the log to me. I will tell you what object caused the issue but I probably cannot tell why. To do so I need to drill down into the problem having the configuration. It’s not necessary to minimize it. All I need is an instruction how to reproduce the error and the configuration as it is.

It doesn't matter. Same problem with documents, catalogs.

There were no EXCP or TLOCK events generated. However, fr om SDBL log I managed to identify the exact cause of my problem.
1. At first I noticed a bunch of queries generated when checking if a new catalog object can be deleted in "Find and Delete Marked Objects":

2. Then I mapped Reference5243, Document4983, InfoRg4020, etc. to configuration objects.
3. After some trials with these configuration objects I identified the cause of my problem:

If information register with data lock control mode = "Automatic" contains a dimension of specific type (AnyRef or CatalogRef for catalogs; AnyRef or DocumentRef for documents) and this dimension is marked as "Master" it prevents the deletion of any catalogs or documents with data lock control mode = "Managed" with this error:
Lock manager use error
Automatic lock mode is not allowed in this transaction.

“There were no EXCP or TLOCK events generated.”

There is no way the platform could fail to register the EXCP event for the error you see. Either you look in a wrong log or the logcfg.xml file wasn’t read on time to change the log settings.

“it prevents the deletion of any catalogs or documents with data lock control mode = "Managed"”

Well, this is exactly what I told you about in my first answer.

There is an object that has depending register. The object is in Managed lock mode and the register is in Automatic mode. When the platform deletes the object it has to delete all its depending register data as well. But the transaction is opened in Managed lock mode so it cannot allow to delete any objects having Automatic mode.

“If information register with data lock control mode = "Automatic" contains a dimension of specific type (AnyRef or CatalogRef for catalogs; AnyRef or DocumentRef for documents)”

We do not recommend using of AnyRef types “just in case” without very clear understanding why you need that wide type definition and how you plan to use it. These types could be very troublesome in some situations. It would be much better to get a clear vision of all particular ref types you really need in this field and confine the type definition to those types only.

I used this cfg file to generate the log:

I repeated my experiment again. The only exceptions I see are from the Background jobs that cannot access the database because "Delete Marked Objects" puts it in the Exclusive Mode.

Yes, the key here was to identify what exact condition is causing it.

Two of the three such registers in our configuration are inherited from the original 1C configuration, the third one was added by us. We will evaluate if it is possible to get rid of AnyRef types.

Thank you for your help.

I repeated my experiment again. The only exceptions I see are from the Background jobs that cannot access the database because "Delete Marked Objects" puts it in the Exclusive Mode.

Just tried it by myself and can confirm that there are no signs of the error in tech log or events log. It looks like an error for me. I will discuss this with the platform developers and post their feedback later.

Two of the three such registers in our configuration are inherited from the original 1C configuration.

I can try to find out what did they mean if you give me the registers names. Probably the registers are very widely used and that wide type definition makes sense. Or it can be just an error.

Thank you, but there is no need for that. The registers are very widely used as they implement universal mechanism for storing custom categories and properties for catalogs and documents.