300

When you successfully deployed Fourtytwo on Azure, you can use the following to fire T-SQL:

• SQL Azure Management (in SilverLight) via Windows Azure Portal
• SQL Server Management Studio

Fourtytwo uses a very small SQL Azure database (1GB Web edition) to manage files, tasks. In fact inside this database we only have 6 tables and 2 stored procedures, yet they are able to provide all the concurrent control, expiring and retry logic.

For our flexibility we didn't enforce 'Foreign Key' relationships on the 4 tables at right hand side, otherwise you shall see arrowed lines link them together as normal ER model does: TaskRun depends on TaskType and FileBlob, in turn TaskType and FileBlob depends on FileType. TaskLock and Workers are standalone entities.

Now we show the purpose of each table:

 
This is a non-essential housekeeping table, when deployment starts, each instance will insert one row here to answer the 'roll call' (kind of, more like shouting aloud I'm alive). You can keep on checking this after you started the deployment, once you saw rows here it means Worker Roles have no problem contacting SQL Azure database, otherwise it means serious trouble.

• The only non-essential table
• Safe to clean up at any time
• Column Name is the WINS name of the instance, you can use it for PowerShell Remoting if you enabled Windows Azure Connect

If you have read the example recipe page, you will see this is the concrete thing to hold a line of Task Type definition.

• Suggest you to leave IsEnabled = 0 when you are doing the Insert, only enable it when you are ready to run the task
• Any row with IsEnabled = 1 will effect immediately, i.e. new run will spin up after a Insert, no run will spin up after a Delete
• The core table you need to fire Insert, Update, Delete on

This is a new concept we didn' mention in the recipe page. A Task Run is a combination of a File and a Task Type. Each row 'potentially' means a run of the task on one of the instance (you can see which by column InstanceID).

• If you see '9999' in the ExpireTime column, this means a run is 'registered' but didn't run because it was part of a multiple file run (i.e. many-to-one), only when all input files are ready will you see a run with a real time indicates a real run.
• ExpireTime is StartTime + 2 hours, this is now hard coded, if your program doesn't end within 2 hours, it will be killed on the instance and could be spin up again on another instance. We might in the future allow you to define your own time span.
• If you keeps on checking this table, you might notice ExpireTime got updated sometimes, this is due to the extra file upload and download (all takes time), we take this into account and leave a real 2 hours for the program.
• You can check the whole command line got fired after all the variable replacements to see if you defined the Task Type correctly by looking at column Command. Well, if you got anything wrong you shall see it immediately, but if it managed to run at all, you'll only see it after it finished the run.
• You can play with column ExpireTime to manually expire a run.
• If you Delete a row from this table yet related TaskType and FileBlob still around, it will be spin up again.

This is for internal usage. For the situation that only one instance can do something special, who ever won the lock will run and others will wait.

Again you shall recognize this is how you define a File Type. This should be ready before running, but you can also Insert new row when you need it.

This is a loose mirror of files in the container. By 'loose' we mean that currently if you remove a row from this table the file in the container won't be deleted, and vice versa if you delete a file from a container if the row already exists it won't get deleted.

• Only container defined in Task Type Container_in will be scaned, for matching File Type.
• You can check if your File Type regular expressions work or not by looking at columns NameBase and NameOrder.