The 1C:Enterprise developers forum

#1
People who like this: 0 Yes / 0 No
Active user
Rating: 2
Joined: May 15, 2013
Company:

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

The accumulation register (Type=Balances) I try to convert uses a query with "UPDATE FOR" clause to check the balance before updating.
Do I need to use a DataLock object to lock this register before writing to it instead of a query with "UPDATE FOR"?

Which method (DataLock vs. FOR UPDATE) has a better performance for concurrent access of this register?

 
#2
People who like this: 1 Yes / 0 No
Active user
1C:Professional
Rating: 6
Joined: May 8, 2013
Company: 1C Company

When you need to check the balance of accumulation register you have two options:

1. Check it using query before writing the register record set.

In Automatic lock mode the query has to have FOR UPDATE option, otherwise there is a possibility of deadlock with other user doing the same operation.

In Managed mode FOR UPDATE option will be ignored so you need to use an explicit exclusive managed lock before the query execution. The lock need to protect all balance records involved in you transaction.

2. You may choose to check the balance after writing the record set. Usually this method is better choice in terms of overall system performance, so we recommend it.

In Automatic lock mode you just write the record set and then check the balance with query (no need to use FOR UPDATE in this case).

In Managed mode you need to switch on the RecordSet.LockForUpdate property before writing the record set, otherwise there is a possibility of deadlock.

Let’s summarize. There is no question “what is better - explicit lock using DataLock object or query with the FOR UPDATE option”  because in Automatic mode you cannot use DataLock object while in Managed mode you cannot use FOR UPDATE option. If you check the balance after you write the record se t (recommended) you don’t need to use any of those but you need to se t in TRUE the RecordSe t.LockForUpdate property.

 
#3
People who like this: 0 Yes / 0 No
Active user
Rating: 2
Joined: May 15, 2013
Company:

Thank you, your answer was very informative and helpful.

 
#4
People who like this: 0 Yes / 0 No
Active user
Rating: 2
Joined: May 15, 2013
Company:

Quote
You may choose to check the balance after writing the record set. Usually this method is better choice in terms of overall system performance, so we recommend it.
Is this method used in 1C:AccountingSuite?

I downloaded the 1C:AccountingSuite v. 1.1.32.76 and looked at the source of SalesInvoice.Posting().

I see what looks like a use of the new method:
Code
// 1. Common postings clearing / reactivate manual ajusted postings
// 2. Skip manually adjusted documents
// 3. Create structures with document data to pass it on the server
// 4. Collect document data, available for posing, and fill created structure 
// 5. Fill register records with document's postings
// 6. Write document postings to register
// 7. Check register blanaces according to document's changes
// 8. Clear used temporary document data


However, when I debugged the code I noticed that the balance check is not executed at step 7, but later:
Code
// OLD Posting
...
If NOT AllowNegativeInventory Then
   Cancel = True;
   Return;
EndIf;


What is the situation with 1C:AccountingSuite?
Is there a configuration available where I could study this method to understand it fully?

 
#5
People who like this: 0 Yes / 0 No
Active user
1C:Professional
Rating: 6
Joined: May 8, 2013
Company: 1C Company

Quote
// 8. Clear used temporary document data

I am not really sure what do you mean by this. There is no temporary data created in any of the steps you listed so I cannot see a need to clear anything.

Quote
Is there a configuration available where I could study this method to understand it fully?

You can take 1C:Small Business 1.4 as an example. For instance there is a document Invoice which Posting procedure includes the following text:

Code
// Write recordsets.
SmallBusinessServer.WriteRecordSets(ThisObject);

// Control
Documents.Invoice.RunControl(Ref, AdditionalProperties, Cancel);    

 
Subscribe
Users browsing this topic (guests: 2, registered: 0, hidden: 0)