While-WEnd Question

[guinness]

My understanding of proper usage of Local declaration in "Global scope".

#include <Constants.au3>

Local $sVar = 'This variable is only used in the scope it''s declared in, therefore imagine if this scope was wrapped in a function called "Main".'
Global $g_sString = 'This variable is used not only in this scope ("Main") but also inside other functions e.g. SomeFunc()'

SomeFunc()

MsgBox($MB_SYSTEMMODAL, '', $sVar) ; Display in a MsgBox().
$sVar = ''

SomeOtherFunc()

Func Example()
    Local $sText = 'This is some text.' ; The variable is Local and is declared and initialised when required.
    ConsoleWrite($sText & @CRLF) ; Display in the console.
    
    $sText = 'Change the variable which is local to the scope it''s declared in.' ; Change the variable's contents.
    ConsoleWrite($sText & @CRLF) ; Display in the console.
EndFunc

Func SomeFunc()
    $g_sString &= @CRLF ; Append CRLF to the string.
    ConsoleWrite($g_sString) ; Display in the console.
EndFunc

Func SomeOtherFunc()
    $g_sString = '' ; Clear the contents of the Global variable.
EndFunc

[JohnOne]

Could you please explain more detail about the "queue control script on the server machine"? Which server? the MySQL server?

Wherever the the MYSQL server is located.

A script which handles a queue of queries from clients, only that 1 script passes those queries on the MYSQL at timed intervals.

That script is a whole other kettle of fish, but you'll probably find one on the forums.

[markyrocks]

No, it is not saved on a separate .au3 file and I dont think this is the issue

I don't think you're understanding what I meant. Not saying it would be an issue. Saying that if say 2 pcs press "functionbutton" 100ms apart pc 1 would run say function.au3 pc2 checks if processexists (funtion.au3) then wait till process does not exist plus 200ms. Not formatted exactly that way but gets my point across. If a few people need to use it this maybe small time solution. If 100's are trying to use it then you'd have issues. Would mainly be luck as to who was next to use it. There would be no rhythm or reason to it. Edited December 16, 2013 by markyrocks

[kylomas]

michaelslamet,

I would do as BrewmanNH suggested and let the DB do the work.  I don't understand it offhand but it seems like table locking/unlocking and/or transactions should be all you need to ensure the integrity of your DB.

Perhaps a DB programmer wll weigh in on this?

kylomas

[michaelslamet]

michaelslamet,

I would do as BrewmanNH suggested and let the DB do the work.  I don't understand it offhand but it seems like table locking/unlocking and/or transactions should be all you need to ensure the integrity of your DB.

Perhaps a DB programmer wll weigh in on this?

kylomas

 

Thank you, kylomas

What I've done for now is changing the table engine from InnoDB to MyISAM since I read that InnoDB doesn't support table locking.

What I need to figure out is now where to put the LOCK and UNLOCK TABLES command

[AutID]

If you are between using lock/unlock and your function then take the 1st solution. You are reading milliseconds. Your function will take definitely more than 200 milliseconds to return since you are using array delete function twice so it would be something more than useless...

[michaelslamet]

If you are between using lock/unlock and your function then take the 1st solution. You are reading milliseconds. Your function will take definitely more than 200 milliseconds to return since you are using array delete function twice so it would be something more than useless...

 

This is really a good idea, I should try speed up the process, including try to remove the array delete function, thanks for that!

What is 1st solution anyway?

[AutID]

_{What BrewManNH suggested is the 1st solution}

[BrewManNH]

If you're looking to lock the table, you put the lock command just before the update/commit commands.

http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html

[kylomas]

 

<delete> incorrect response to AutID

michaelslamet,

The first function is the DB solution.

 

1 - construct Log record

2 - lock table (or whatever the appropriate terminology is)

3 - write table record

4 - unlock table

I would figure out how connections, transactions and locking work in whatever DB solution I use and implement it that way.

kylomas

edit: deleted response noted above

Edited December 17, 2013 by kylomas

[jchd]

Rather than locking the DB (or part of it, depending on the DB engine capabilities), I'd rather use standard SQL-way to implement a kind of IPC. Create a table `Timer` with only one row and one column `lasttime` where you store the time of last access within a transaction.

Now in your access function, start an immediate transaction, select the difference between the current time and `lasttime` and either wait loop until it is > 200ms. Once the delay has elapsed, grab the rows you need then update `lasttime`, all within the transaction. This way, you can be sure that only one process can access the precious row within any 200ms period.

I'm not familiar enough with the terrible intricacies of MySQL to offer working code but I don't see why it wouldn't work.

[JohnOne]

May I ask what the logic behind wanting this 200ms limit is?

[kylomas]

Hi jchd,

I don't think the OP is trying to implement IPC.  I think his concern is writing log records from multiple places to a single table (please correct me if I'm wrong michaelslamet).   

I don't understand transactions, locking and unlocking in enough detail to offer anything more than the technique as a possiblilty.  It seems better to let the DB handle serialization of writing records, if it can. 

kylomas

[jchd]

Want it or not it's a kind of IPC centralized and deported to the DB side. ClientA says "last time written is T₀", clients B thru Z have to wait until T₀ + 200ms.

That can be translated to a pure IPC communication: client A broadcasts message "I just wrote a record" (e.g. MailSlot or UDP or whatever) and all other clients have to wait 200ms from receiving that to be allowed to compete for reading said record. This even makes it more subtle: clients just launched have to wait 200ms inconditionnally for that scheme to work reliably (may not have received a previous message).

[michaelslamet]

Rather than locking the DB (or part of it, depending on the DB engine capabilities), I'd rather use standard SQL-way to implement a kind of IPC. Create a table `Timer` with only one row and one column `lasttime` where you store the time of last access within a transaction.

Now in your access function, start an immediate transaction, select the difference between the current time and `lasttime` and either wait loop until it is > 200ms. Once the delay has elapsed, grab the rows you need then update `lasttime`, all within the transaction. This way, you can be sure that only one process can access the precious row within any 200ms period.

I'm not familiar enough with the terrible intricacies of MySQL to offer working code but I don't see why it wouldn't work.

 

Thank you, jchd. This is the first time I heard word "IPC". Googling bring me some great explanation at wikipedia. Interesting.

I had a chance to escape from a tight loop at my script, so right now (I think) the database lock solution working great.

I will not really sure until it's put to run in the production environment, but I think it's enough for now, so I'm going to mark this as solved.

Thanks everybody!

[michaelslamet]

May I ask what the logic behind wanting this 200ms limit is?

 

That 200ms can be any number

[michaelslamet]

 

 

<delete> incorrect response to AutID

michaelslamet,

The first function is the DB solution.

 

1 - construct Log record

2 - lock table (or whatever the appropriate terminology is)

3 - write table record

4 - unlock table

I would figure out how connections, transactions and locking work in whatever DB solution I use and implement it that way.

kylomas

edit: deleted response noted above

 

Thank you, kylomas. This is what exactly I'm doing as a solution for this problem (see my previous post).

Thanks again!