Multiple istance AutoIt from different computers

[FrancescoDiMuro]

Good morning
I'd like to know if someone else here has already tried to use an AutoIt script which work on the same DB ( i.e. SQLite ) on different Computers.
If yes, please answer here, because I'd like to develop it, and I don't know where to start ( i.e. , I don't know how the script would work if 2 or more users are writing/reading in the same moment... )  
Thanks! 

Edited March 20, 2017 by FrancescoDiMuro

[genius257]

Hi @FrancescoDiMuro.

I think reading about Isolation (database systems) might help you with this, as it's not so much the application as it is the database settings.

[FrancescoDiMuro]

Thanks for the reply @genius257!
I was thinking about that! I'm going to take a look!  
Thanks  

Edited March 20, 2017 by FrancescoDiMuro

[jchd]

The problem isn't multiple instances of AutoIt, not even multiple concurent connections to the same SQLite DB. The possible cause of issues is with the network file locking protocols which may fail in some more or less bscure situations. SQLite isn't a client/server engine and isn't the best choice where remote concurency occurs at significant rate.

That said, modern OSes (typically Win >= 7) seem to work flawlessly from this point of view AFAIK. Yet if you plan many users and significant concurency, your best choice will be a client/server engine (PostgeSQL for instance) and use of ODBC/ADO (lookup the ADO UDF by Mlipok).

Nonetheless if you can afford some network delay and don't plan high concurency, you still can use SQLite. There is an UDF here within the Examples section which uses file semaphores to avoid issues. Of course it's even slower than bare SQLite.

In low-concurency contexts and provided your application isn't mission- or life-critical, you can still use bare SQLite if you follow these guidelines (the same apply to multiple processes accessing a local SQLite DB, as well as using any client/server SQL engine with some changes to adapt to a given SQL dialect):

Once for all, connect to the DB and issue "pragma journal_mode = WAL" to set the DB in WAL mode, which allows one writer and multiple readers concurently. Do this once as the setting will be permanent until changed (don't change it!).

Right after creating any connection to the shared DB, issue _SQLite_SetTimeout with the maximum time that the longest possible transaction sequence might take. I could expand on why this pedantic phrasing, but let's say you set a 30 minutes timeout, or anything very long. Genuine client/server engines use more sophisticated locking and caching techniques, so this is merely a SQLite-specific thing.

Use "BEGIN IMMEDIATE" transactions around any sequence of SQL statements which need to be atomic (e.g. RMW = read, modify, write). Also use transaction around sequences of statements within _SQLite_Exec when the whole operation needs to be atomic.

If your application needs to read data, show it to a user, process the decision taken and then only update the DB, realize that when wrapped in an immediate transaction, the DB will get locked to other writers. If the user takes longer than the timeout value, other writers will receive SQLITE_BUSY error. The worst case is when data is read, awaiting user action and that the app crashes or PC is powered down or the user returns home or whatever situation where the transaction isn't terminated with either a COMMIT or a ROLLBACK. In this case, the best move is to have a dedicated column in shared tables which holds the user ID "owning" the row(s) and awaiting possible change. Only when a row holds NULL is it available for use in a RMW transaction.

Test the error value after all SQL function invokation and act accordingly.

 

[FrancescoDiMuro]

@jchd
Thank you for you detailed answer
I started using SQLite few months ago ( we talked in pm too ), but It was already familiar because I studied SQL ( just the basic ) more than 3 years ago
So, I'm not as acculturated as I would be to reply to you, and so, I'm sorry for that...
Maybe, explaining in my best way what I'd like to do, you can suggest more directly what could be the solution
With my DB, queries I do are:
- SELECT, just 1 SELECT with a LEFT JOIN between 2 tables;
- INSERT;
- UPDATE.

I don't do anything else with the DB.
Users would be 3.
If you can help me more "basic-like", I'd very appreciate your help ( that I can understand )
Thanks again for your detailed answer  

[jchd]

Lone or group inserts aren't a problem even if grouping bulk inserts in a transaction cuts wall clock by a large factor.

Lone selects aren't a problem either.

Where issues arise is when USER_A does:

1 - SELECT some_data
2 - let the user decide what to do, change, whatever, possibly after taking his/her lunch
3 - UPDATE whatever_needs_to_be_updated

If USER_B changes (UPDATE or DELETE) something in the resultset of step 1, or INSERT something that should have been part of that resultset, while USER_A is in step 2, then the DB might become inconsistent.

Edited March 20, 2017 by jchd

[FrancescoDiMuro]

2 minutes ago, jchd said:

Lone or group inserts aren't a problem even if grouping bulk inserts in a transaction cuts wall clock by a large factor.

Lone selects aren't a problem either.

Where issues arise is when you do:

SELECT somedata

I do SELECT * and SELECT column_name(s).
 

 

Edited March 20, 2017 by FrancescoDiMuro

[jchd]

Sorry for hitting the wrong key, previous post completed now.

Think of a bank account with $1000 credit and no authorization to go in debt.

At some time the owner wants to get money from an ATM. He selects $800.  At the same time a $500 check is processed by the bank.

If the ATM checks the account, verifies that it allows a $800 withdrawal, updates the account to become $200 while it delivers the banknotes, AND if the bank proceeds to the payment of the $500 check after the ATM read the account and before it updates it to $200, the account will become -$300, which is forbidden.

The only way to guard against such inconsistency it to wrap both operations in a transaction, making each payment an atomic operation which either takes place completely as one uninterruptible process or fails (here due to insufficient credit in one of the cases).

You must do:

0 - Begin immediate                ; starts a transaction where writes will likely occur
1 - select ...
2 - process ...
3 - update ...
4 - if all OK then COMMIT (perform changes) else ROLLBACK (quit transaction without any change) and process confilcting situation.

Both the ATM and the check processing need to use a transaction, so only the first one to COMMIT will go to completion, the other will encounter an error when trying to open its own transaction, or rather will wait until timeout to have a chance to let the transaction already started to complete. If you set a large enough timeout value and no dramatic event occurs (app crash), then everything will take place serially, leaving the DB in a consistent state at every time.

SQLite implements IMMEDIATE and EXCLUSIVE transactions by using file locks. Network file locking is know to have been a big problem with all known OSes up to a relatively recent time. The problem is due to bugs and holes in the process of "simultaneously" broadcasting locking information over a network. Nothing is simultaneous with computing, especially in a networked environment. Situation seems to have improved by fixing myriad of bugs in protocols and discarding unreliable ones.

[Skysnake]

Beautiful explanation @jchd.

I had a similar little problem with an embedded SQLite app we used at the office to track paper files movement across the office.  In theory, only one person could handle a file at a time... but it turns out, that's not what happens in reality.

I also think that (a) a different database design or (b) different database solution warrants investigation.

SQLite is not designed for a multi-user environment. 

[FrancescoDiMuro]

2 minutes ago, Skysnake said:

Beautiful explanation @jchd.

I had a similar little problem with an embedded SQLite app we used at the office to track paper files movement across the office.  In theory, only one person could handle a file at a time... but it turns out, that's not what happens in reality.

I also think that (a) a different database design or (b) different database solution warrants investigation.

SQLite is not designed for a multi-user environment. 

And then, how did you solve?
Thanks

[FrancescoDiMuro]

@jchd
Another great explanation, thank you
So, what I have to do, to use simultaneousely the application, is ( always? ), do a transaction and check the returns of that operation.
Am I on the correct path?
Thanks! 

[jchd]

Use IMMEDIATE transactions to make complex processing atomic (all or nothing), set a long timeout on each connection. Always checking return codes is a prerequisite in all situations.

[Gianni]

.... here there is a very instructive example of how to carry out concurrent accesses in read / write mode to an SQLite database (see Post #19).

I used these two scripts to run many instances of a parallel script, and each of them wrote on the same database without problems.

Many thanks again to @jchd!!

Edited March 20, 2017 by Chimp

[FrancescoDiMuro]

@Chimp
Thanks for your help
Yeah, @jchd seems to be very very acculturated on DB
Good job buddy!