MySql revisited

General Help regarding HMG, Compilation, Linking, Samples

Moderator: Rathinagiri

User avatar
BeGeS
Posts: 80
Joined: Fri Jul 14, 2017 10:45 am
DBs Used: DBF
Location: La Mancha, Spain
Has thanked: 15 times
Been thanked: 13 times

Re: MySql revisited

Post by BeGeS » Wed Aug 23, 2017 8:15 pm

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.
I get by with a little help from my friends

User avatar
dragancesu
Posts: 438
Joined: Mon Jun 24, 2013 11:53 am
DBs Used: DBF, MySQL, Oracle
Location: Subotica, Serbia
Has thanked: 3 times
Been thanked: 58 times

Post by dragancesu » Thu Aug 24, 2017 6:43 am

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

User avatar
vagblad
Posts: 93
Joined: Tue Jun 18, 2013 12:18 pm
DBs Used: MySQL,DBF
Location: Thessaloniki, Greece
Has thanked: 5 times
Been thanked: 10 times

Post by vagblad » Thu Aug 31, 2017 11:54 am

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.
Vagelis Prodromidis
Email: vagblad@gmail.com, Skype: vagblad

User avatar
BeGeS
Posts: 80
Joined: Fri Jul 14, 2017 10:45 am
DBs Used: DBF
Location: La Mancha, Spain
Has thanked: 15 times
Been thanked: 13 times

Post by BeGeS » Mon Sep 11, 2017 3:18 pm

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.
I get by with a little help from my friends

User avatar
Rathinagiri
Posts: 5148
Joined: Tue Jul 29, 2008 6:30 pm
DBs Used: MariaDB, SQLite, SQLCipher and MySQL
Location: Sivakasi, India
Has thanked: 124 times
Been thanked: 126 times
Contact:

Post by Rathinagiri » Wed Sep 13, 2017 4:30 am

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.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.

Post Reply