Page 7 of 7

Re: MySql revisited

Posted: Wed Aug 23, 2017 8:15 pm
by BeGeS
Rathinagiri wrote:
Wed Aug 23, 2017 7:28 pm
I think everybody is discussing here about concurrence.

It is better to read MySQL documents about locking, begin...commit, and exclusive transactions.

https://dev.mysql.com/doc/refman/5.7/en ... reads.html
Two issues are being discussed.

Claudiotedesco asks how the blockages are made in MySQL, and as a result of this it is raised the necessity or not to realize blockades. In the first thing I can not intervene because I do not know anything, but of the second I have no doubt.

Re: MySql revisited

Posted: Thu Aug 24, 2017 6:43 am
by dragancesu
It's a good example
Imagine such a situation: two sellers sell the same product. Both of them read availability as 100. Everyone try to sell 100. How to control such a situation?
But there are solutions, the database "works" as opposed to the dbf files used to store data

The database function is to store data and it works very well, and there is a possibility to programing, there are triggers, procedures and functions

Here the interesting triggers are here, they are "fire" on events, in this case the current state would be checked and if there is not enough no further action, the classic example for BEFORE INSERT trigger

http://www.mysqltutorial.org/mysql-triggers.aspx

Re: MySql revisited

Posted: Thu Aug 31, 2017 11:54 am
by vagblad
BeGeS wrote:
Wed Aug 23, 2017 5:46 pm
:shock:

Let me show my absolute disagreement with the things you say.

First, this issue has no relation to duplicate records. What's more, I open all files with the possibility of duplication and then decide where it can be and where not.

Neither is it related to old hardware and software, since blockages are common sense.

I can imagine the lack of blockages in certain situations (real) of some of my clients: the chaos could reach biblical proportions, and the culprit would be me. :cry:

In short, for me, locks are essential in database manipulation, whatever the type, and I can not imagine how they can be dispensed with in a serious application. The last one to record is the winner? Wow!

Greetings.
What's more, I open all files with the possibility of duplication and then decide where it can be and where not.
I don't get the sarcasm of your post on my opinion of table/record locking. Especially the part "The last one to record is the winner? Wow!".

I'll try and clarify my view and won't come back on the subject, because Dragan's thread has already been derailed a bit.
Locks are not essential with databases like MySql. Yes you can use them and they work. You can avoid locking in most situations. In my opinion not the best practise anymore except on specific niche situations but not in a whole database system. Using transactions and triggers can cover almost anything.Yes maybe in banking system you may need locks at certain places as Serge said. I don't have any experience with banking systems but i can understand where you might need a lock.
In Mol's example using transcations and a trigger on the stock field would solve the problem without locking.

Re: MySql revisited

Posted: Mon Sep 11, 2017 3:18 pm
by BeGeS
Vagblad, excuse me if I have bothered you. You considered a sarcasm what was just a joke. And I also played as a joke what you said: "Easy, mark the username field as unique again. It will never allow you to enter the same name, it will always return an error code".

I have the impression that we are talking about different issues, different problems and different solutions. For example, a food distribution company that has references with lot number and expiration date, always needs the locks at the moment the vehicles load (all at the same time) while in two or three teams is performed simultaneously product output and attached document. Without these locks, the warehouse could be completely out of control.

And for example, an application to register the census of inhabitants of a city, however large it may be, does not need those same blockades. Neither do you need a mobile phone company or a doctor to record appointments of your patients.

It is not about "niches" but about the nature of the application.

Regards.

Re: MySql revisited

Posted: Wed Sep 13, 2017 4:30 am
by Rathinagiri
For various purposes MySQL has the following types of locks available:

1. Shared and Exclusive Locks
2. Intention Locks
3. Record Locks
4. Gap Locks
5. Next-Key Locks
6. Insert Intention Locks
7. AUTO-INC Locks

You can see them in detail here.