1

Topic: Locks in a business layer

All kind Now I will sound a problem, for certain I not the first who face it also decisions for a long time already are known, but is visible they to me did not come across or were not remembered. It is a question of the task of support of an invariance of a state of business objects till the end of business operation in the multiple user environment. We present that there is any operation, on business to rules it can be successfully fulfilled only at a certain state of any objects. How we implement it? In the code at first we read these objects, we check their state and if it corresponds to business rules we fulfill operation. In the multiple user environment here there can be problems: the state of checked objects can change between reading of objects and operation performance that as a matter of fact it leads to performance of operation with violation of business rules. Gravity of such violation can vary is is sometimes admissible, and sometimes is not present (on one place is sold two tickets). For avoidance of such situation it is logical to fulfill lock of the read objects till the end of operation so that anybody another could not change their state. Here there is no speech about check a state of the changeablest object - the decision through "optimistic lock" is known. I speak about stability of a state of other logically bound entities, which do not change operation. The first decision which basically already works, this usage of serializable-transactions on basis. Here as a matter of fact all locks are fulfilled by basis. Scales and volume of locks in basis as a whole  that somehow it is necessary to affect them densely to sit down structure of basis and requests. This decision has still lacks: appear  in process of growth of loading and an amount of the involved tables, does not envelop the data which are not read from basis (are in  - reference manuals). What other decisions can advise? To write the lock manager? There are examples? Technologies and architecture:.NET,  Desktop Client - WCF services on IIS, EF - MS Sql Server, there is no horizontal scaling.

2

Re: Locks in a business layer

Hello, Poul_Ko, you wrote: P_K> What other decisions can advise? LMAX disruptor . If briefly all the information is stored in storage, the output agent one-continuous. Operations (to reserve the ticket) are read from locking queue. Then the data in storage, without locks, since the output agent one-continuous changes. Further CQRS: the information that exchanged, written in persistent queue. At restart of application the data in storage is recovered by "replaying" of all written down events over some starting state.

3

Re: Locks in a business layer

Hello, Poul_Ko, you wrote: P_K> All kind P_K> Now I will sound a problem, for certain I not the first who face it also decisions for a long time already are known, but is visible they to me did not come across or were not remembered. : dares the "correct" designing. I.e. such that a place in which lock / synchronization is carried out was as it is possible smaller, in an ideal - one atomic increment/updating of a field. Not, I say lies. In an ideal - that necessities for transactions were not generally. To distinguish the correct designing from wrong it is very simple: if the command regularly leads a round dance round the code with arguing "well and what now with all it to do?" - Precisely wrong Decisions there can be a ton. In  systems registration of pools of resources behind each separate machine (we tell, the pool is registered for 5 minutes everyone of 30 seconds lasts) can work. It can be booking flag activation on a separate resource (besides with time mark when there was a booking). It can be try-update loop - optimistic concurrency + retry if it did not turn out. In especially desperate deals it is possible even to fasten distributed lock or to implement handling by forces only one flow on one of machines (well and to keep in readiness the second  on grab). All depends on specific scenarios and from experience/preferences in a command.

4

Re: Locks in a business layer

Hello, Poul_Ko, you wrote: P_K> All kind P_K> Now I will sound a problem, for certain I not the first who face it also decisions for a long time already are known, but is visible they to me did not come across or were not remembered. P_K> it is a question of the task of support of an invariance of a state of business objects till the end of business operation in the multiple user environment. P_K> we present that there is any operation, on business to rules it can be successfully fulfilled only at a certain state of any objects. How we implement it? In the code at first we read these objects, we check their state and if it corresponds to business rules we fulfill operation. In the multiple user environment here there can be problems: the state of checked objects can change between reading of objects and operation performance that as a matter of fact it leads to performance of operation with violation of business rules. Gravity of such violation can vary is is sometimes admissible, and sometimes is not present (on one place is sold two tickets). P_K> For avoidance of such situation it is logical to fulfill lock of the read objects till the end of operation so that anybody another could not change their state. P_K> Here there is no speech about check a state of the changeablest object - the decision through "optimistic lock" is known. I speak about stability of a state of other logically bound entities, which do not change operation. P_K> the first decision which basically already works, this usage of serializable-transactions on basis. Here as a matter of fact all locks are fulfilled by basis. Scales and volume of locks in basis as a whole  that somehow it is necessary to affect them densely to sit down structure of basis and requests. P_K> this decision has still lacks: Appear  in process of growth of loading and an amount of the involved tables, does not envelop the data which are not read from basis (are in  - reference manuals). P_K> What other decisions can advise? P_K> to write the lock manager? There are examples? P_K> technologies and architecture:.NET,  Desktop Client - WCF services on IIS, EF - MS Sql Server, there is no horizontal scaling. Look lock with a low level of detailing.

5

Re: Locks in a business layer

Hello, scf, you wrote: scf> LMAX disruptor . If briefly all the information is stored in storage, the output agent one-continuous. Operations (to reserve the ticket) are read from locking queue. Then the data in storage, without locks, since the output agent one-continuous changes. Further CQRS: the information that exchanged, written in persistent queue. At restart of application the data in storage is recovered by "replaying" of all written down events over some starting state. Thanks, are interesting. If I correctly understood, a decision essence in an exception of a source of a problem - multi-threaded execution. All operations are fulfilled sequentially, round it the certain infrastructure raising productivity is wound. I am afraid that for the project in its current state passage to such model demands too many forces and time.

6

Re: Locks in a business layer

Hello, Sinix, you wrote: S> Kep: dares the "correct" designing. I.e. such that a place in which lock / synchronization is carried out was as it is possible smaller, in an ideal - one atomic increment/updating of a field. Abruptly. I as  also ask examples of "correctly designed decision. S> in  systems registration of pools of resources behind each separate machine (we tell, the pool is registered for 5 minutes everyone of 30 seconds lasts) can work. I would not carry our system to . You speak About what separate machines? All on one server, is written in the first message... S> It can be booking flag activation on a separate resource (besides with time mark when there was a booking). What for a flag, what behavior at it and characteristics, what for time mark? S> it can be try-update loop - optimistic concurrency + retry if it did not turn out. Optimistic concurrency the problem absolutely in other works within the changeable aggregate, and in my case. Or my understanding optimistic concurrency differs from yours. S> in especially desperate deals it is possible even to fasten distributed lock or to implement handling by forces only one flow on one of machines (well and to keep in readiness the second  on grab). What is it? Again any distribution? It is not present at me. S> All depends on specific scenarios and from experience/preferences in a command. Pepper Similar our and your scenarios/preferences very strongly is clear differ.

7

Re: Locks in a business layer

Hello, Qulac, you wrote: Q> Look lock with a low level of detailing. An efficient sentence. If I correctly understand it, an essence in the organization of the mechanism of the locks operating not with separate entities, and any more general concepts as though "covering" logically bound dial-up of entities. Roughly speaking, at ticket sale at cinema we lock all cinema hall, instead of a separate place. Any libraries /  decisions / best practices for this purpose are known?

8

Re: Locks in a business layer

Hello, Poul_Ko, you wrote: P_K> Hello, Qulac, you wrote: Q>> Look lock with a low level of detailing. P_K> an efficient sentence. If I correctly understand it, an essence in the organization of the mechanism of the locks operating not with separate entities, and any more general concepts as though "covering" logically bound dial-up of entities. Roughly speaking, at ticket sale at cinema we lock all cinema hall, instead of a separate place. A classical example here is Order and OrderItem. At editing OrderItem it is locked Order and all it OderItem. Lock can be as optimistic and pessimistic. P_K> any libraries /  decisions / best practices for this purpose are known? There that difficult, the decision at Fowler in the book on architecture see.

9

Re: Locks in a business layer

Hello, Qulac, you wrote: Q> the Classical example here is Order and OrderItem. At editing OrderItem it is locked Order and all it OderItem. Lock can be as optimistic and pessimistic. Here it in my opinion just not that. It is one aggregate. The aggregate is unit of support of integrity and consequently it always should be processed entirely, including be locked with that or otherwise. I speak about other. For example, you create the order. The order for the client, at the client is any percent of a discount, and accordingly in the order you should put down this discount on all positions. The in itself client is not a part of the aggregate of the order. But for the period of operation of creation of the order we should provide an invariance of percent of a discount of the client. Otherwise there is a risk to create the order at a discount which is not so valid (has been changed parallely with order creation). A question in that how to provide this invariance. We take the decision by means of locks. Object of lock we will have a client. That is, for the period of order creation we lock the client for whom there is an order. Now we develop a subject. Cost of a line of the order is added from the price and a discount of the client. At a discount understood, the prices undertake from the price-list. Means for the period of order creation it is necessary to lock also the price-list (entirely - in it sense of the approach " locks"). In a reality it turns out that for the period of order creation it will be necessary to lock a heap of different things, and it is not becomes eliminated necessity of lock of some it is clear only in process. It means that there can be deadlocks that complicates the decision... So with a phrase "There that difficult" I would argue

10

Re: Locks in a business layer

Hello, Poul_Ko, you wrote: P_K> Hello, Qulac, you wrote: Q>> the Classical example here is Order and OrderItem. At editing OrderItem it is locked Order and all it OderItem. Lock can be as optimistic and pessimistic. P_K> here it in my opinion just not that. It is one aggregate. The aggregate is unit of support of integrity and consequently it always should be processed entirely, including be locked with that or otherwise. P_K> I speak about other. P_K> for example, you create the order. The order for the client, at the client is any percent of a discount, and accordingly in the order you should put down this discount on all positions. P_K> the in itself client is not a part of the aggregate of the order. But for the period of operation of creation of the order we should provide an invariance of percent of a discount of the client. Otherwise there is a risk to create the order at a discount which is not so valid (has been changed parallely with order creation). P_K> the Question in that how to provide this invariance. We take the decision by means of locks. Object of lock we will have a client. That is, for the period of order creation we lock the client for whom there is an order. P_K> now we develop a subject. Cost of a line of the order is added from the price and a discount of the client. At a discount understood, the prices undertake from the price-list. Means for the period of order creation it is necessary to lock also the price-list (entirely - in it sense of the approach " locks"). P_K> In a reality it turns out that for the period of order creation it will be necessary to lock a heap of different things, and it is not becomes eliminated necessity of lock of some it is clear only in process. It means that there can be deadlocks that complicates the decision... P_K> So with a phrase "There that difficult" I would argue Problems of competitive access it is a natural problem of data access. The user (customer) should sound, as your program in such cases should work. Disconnexion of business transactions are a part .. On your program. And so to reflect on the abstract things - a waste of time.

11

Re: Locks in a business layer

Hello, Qulac, you wrote: P_K>> For example, you create the order. The order for the client, at the client is any percent of a discount, and accordingly in the order you should put down this discount on all positions. P_K>> the in itself client is not a part of the aggregate of the order. But for the period of operation of creation of the order we should provide an invariance of percent of a discount of the client. Otherwise there is a risk to create the order at a discount which is not so valid (has been changed parallely with order creation). Q> Problems of competitive access it is a natural problem of data access. The user (customer) should sound, as your program in such cases should work. Disconnexion of business transactions are a part .. On your program. And so to reflect on the abstract things - a waste of time. Your thought did not understand. We return for example. At order creation the discount of the client should be used. It also is task setting, and it was strange if it sounded somehow so:" At order creation the discount of the client should be used, but is admissible if system  and other discount which was till the moment of creation of the order will be used."

12

Re: Locks in a business layer

Hello, Poul_Ko, you wrote: S>> In  systems registration of pools of resources behind each separate machine (we tell, the pool is registered for 5 minutes everyone of 30 seconds lasts) can work. P_K> I would not carry Our system to . You speak About what separate machines? All on one server, is written in the first message... Well, in that case , there is no sense generally to carry out locks and  as something deserving separate attention from the business code. For overwhelming number of records the number of conflicts or is reduced to 0, or there is enough last wins (for example, the data of a user profile or dictionary records which practically are not corrected). Remain * resources which on determination are exhaustible (the same room reservation, for example) * so-called Business transactions (transfer from the account into the account, we we tell) * dumbass-requirements of a type of consecutive numeration of orders without holes For these rare occurences - yes, it makes sense to be confused, outline current biz-process in the form of the chart to estimate possible variants of races and already proceeding from this knowledge to try to rewrite something in respect of architecture. The common decision is not present, if there is a specific example - it is possible to consider.

13

Re: Locks in a business layer

Hello, Sinix, you wrote: S> the Common decision is not present, if there is a specific example - it is possible to consider. The common example has been sounded in a branch of dialogue with . Qulac. So, there is a business operation "to Create the order". The order for any client on any goods from the reference manual. The client has any discount, the goods in the reference manual has any price. The Business rule: at order creation to take a discount of the client and to apply it to the current price of the goods in the reference manual. Further, the order can be in a state "" and "is confirmed". There is it in a state "". Business requirements: at change of a discount of the client it is necessary to enumerate cost of its orders in the status "". At change of the price of the goods in the reference manual it is necessary to enumerate cost of all orders in the status "" which include these goods. Conceptually the state of essence "order" depends on a state of the bound entities "client" and "goods". Let's return to operation of creation of the order. As it is implemented in the code: found the client, found the goods, counted cost, created and saved essence of the order. Like all it is good, but we present that change of the price of the goods is parallely fulfilled, say. Transactions go parallely: the first read the goods with the old price and saved the order with it, the second updated the price in the reference manual, but did not see the yet not created order. As a result we have the order with the old price. Business rules are broken. What will be your candidate solutions? The set example is very simplified, actually it is a lot of factors and variants of their influence happen the most different (for example, presence at the client of other not confirmed order forbids to create new).

14

Re: Locks in a business layer

Hello, Poul_Ko, you wrote: P_K> So, there is a business operation "to Create the order". The order for any client on any goods from the reference manual... P_K> What there will be your candidate solutions? And than the mentioned optimistic lock does not arrange? Before order transfer in a state "is confirmed" to check, what changed nothing? And if changed, to show to the user the updated information and to ask acknowledgement again?

15

Re: Locks in a business layer

Hello, MozgC, you wrote: MC> Hello, Poul_Ko, you wrote: P_K>> So, there is a business operation "to Create the order". The order for any client on any goods from the reference manual... P_K>> What there will be your candidate solutions? MC> and than the mentioned optimistic lock does not arrange? Before order transfer in a state "is confirmed" to check, what changed nothing? And if changed, to show to the user the updated information and to ask acknowledgement again? It does not correspond to business requirements, and in the status "is confirmed" we here do not consider order transfer. Let's consider that there is a such global requirement: at not confirmed orders always the size of a discount and the price should correspond to these values from the data of the client and the goods. Bypass manoeuvres it is possible to invent much. For example, it is possible discount and price not to store in the order, and to tighten from the bound entities each time when it is necessary. . But a question not about it, I will repeat, the example is simplified.

16

Re: Locks in a business layer

17

Re: Locks in a business layer

Hello, Poul_Ko, you wrote: P_K> Business requirements: at change of a discount of the client it is necessary to enumerate cost of its orders in the status "". At change of the price of the goods in the reference manual it is necessary to enumerate cost of all orders in the status "" which include these goods. It is a little purchase not so work. The typical requirement (caused by the legislation): the order is paid strictly for that price which has been shown the user at the moment of button click to confirm / transfers on the provider of payment. Price change (for example, if needed to pay  / delivery) is a separate business operation which also should be confirmed by the client (mail or a call - it is unimportant). Otherwise in any way. The prices by the time of __ arrivals of money (and it never the moment of fixing of payment by the provider) can exchange 10 times. From here the elementary decision: At the moment of order fixing to it essence OrderPurchase which stores actual cost of the goods is added. Record of this information - last wins in the pure state. For esthetes it is done the data of reference manuals immutable and it is storable in the warrant id , instead of id records. P_K> like all it is good, but we present that change of the price of the goods is parallely fulfilled, say. Transactions go parallely: the first read the goods with the old price and saved the order with it, the second updated the price in the reference manual, but did not see the yet not created order. As a result we have the order with the old price. Business rules are broken. Anything terrible. Than the situation "cost exchanged one second prior to goods payment" differs from "a second later"?

18

Re: Locks in a business layer

Hello, Sinix, you wrote: S> it is a little Purchase not so work... The Pancake, an example artificial, let's think upon a problem. P_K>> like all it is good, but we present that change of the price of the goods is parallely fulfilled, say. Transactions go parallely: the first read the goods with the old price and saved the order with it, the second updated the price in the reference manual, but did not see the yet not created order. As a result we have the order with the old price. Business rules are broken. S> anything terrible. Than the situation "cost exchanged one second prior to goods payment" differs from "a second later"? Speech not about payment, and about creation nobody the order. The price in it should correspond strictly to the price in the reference manual, till the certain moment in order life. If the price exchanged a second earlier - it will be tightened from the reference manual and the order forms already with the new price. If the price exchanged a second later - the output agent of change of the price finds the order and  it. If the price exchanged at the same time - here where a problem! We can receive the order with the old price, here that it is necessary to overcome.

19

Re: Locks in a business layer

Hello, Poul_Ko, you wrote: P_K> Hello, Qulac, you wrote: P_K>>> For example, you create the order. The order for the client, at the client is any percent of a discount, and accordingly in the order you should put down this discount on all positions. P_K>>> the in itself client is not a part of the aggregate of the order. But for the period of operation of creation of the order we should provide an invariance of percent of a discount of the client. Otherwise there is a risk to create the order at a discount which is not so valid (has been changed parallely with order creation). Q>> Problems of competitive access it is a natural problem of data access. The user (customer) should sound, as your program in such cases should work. Disconnexion of business transactions are a part .. On your program. And so to reflect on the abstract things - a waste of time. P_K> your thought did not understand. P_K> we Return for example. At order creation the discount of the client should be used. It also is task setting, and it was strange if it sounded somehow so: "At order creation the discount of the client should be used, but is admissible if system  and other discount which was till the moment of creation of the order will be used." Not once read in .. That optimistic lock should be used. Pessimistic lock is in certain cases comprehensible only. For example: the client selected a hotel accommodation and went to fill the questionnaire, number is blocked at this time, in it it is impossible to carry out settlement. All these things are coordinated with the customer.

20

Re: Locks in a business layer

21

Re: Locks in a business layer

22

Re: Locks in a business layer

Hello, Poul_Ko, you wrote: P_K> On an example, we show to the user that the order will be such with the price, it presses the button "to Create the order", the data leaves on the server, whether there will be checked up there corresponds the price in the reference manual of that which was on the screen is and there is an optimistical lock. The price does not correspond - we show an error "the Price exchanged". The price corresponds - we create the order. And at this time the price in the reference manual changes. The order forms with the old price in the transaction, the price in the reference manual changes in the. As a result the business rule is broken. The problem can be solved at DB level. For example in transaction with level Repeatable Read to read the prices from the reference manual (the read lines from the reference manual will be blocked also the prices cannot exchange other transactions), to compare, and if all  - to confirm the order and  transaction. If it would be desirable to avoid lock (which in general most likely will be on a fraction of a second) it is possible generally one request, type (write approximately without check): UPDATE [Order] SET Status = Confirmed WHERE OrderID = X AND (SELECT COUNT (*) FROM OrderItem i INNER JOIN Price p i. ItemID = p. ItemID i. Price = p. Price WHERE OrderID = X) = ItemsInOrderCount

23

Re: Locks in a business layer

Hello, Poul_Ko, you wrote: S>> it is a little Purchase not so work... P_K> the Pancake, an example artificial, let's think upon a problem. Not the question, only the decision will be too artificial. P_K> speech not about payment, and about creation nobody the order. The price in it should correspond strictly to the price in the reference manual, till the certain moment in order life. Well so to store in "order" the link to reference manuals and to consider the price dynamic. If value in the reference manual regularly changes - to store the link to record of history of the reference manual. The only thing but: from experience approximately through 3-4 iterations in the same spirit the project or , or passes to a command which prefers to repair real problems (including softening of requirements) instead of race for . P_K> If the price exchanged a second later - the output agent of change of the price finds the order and  it. Even the modest basis on pair millions orders and process of update of the price becomes very interesting occupation. Especially if the letter with the previous price is already sent the client. P_K> if the price exchanged at the same time - here where a problem! We can receive the order with the old price, here that it is necessary to overcome. From what it? You say, what the output agent of change of the price finds and updates the order? Or the output agent is made by the synchronous, that was more cheerful?

24

Re: Locks in a business layer

25

Re: Locks in a business layer