Skip to Content

Some collection of information about the way to work with multiple-threads

  • You only need one ADSConnection per ADS Server.  All TAdsTables can share the connection.  However, note that the connections are asynchronous. Meaning you can't do two things at once on the same connection.  If you are going to use multiple threads, you might want to have multiple connections.

    There is nothing mandatory about using a connection component, but it makes things easier in my opinion.  You only have one location to set paths, etc.
    If you use the database name property, the client engine will open a connection implicitly.  Every new table will look for a connection that matches the path.  If one is found it will use the same connection, if not a new connection will be created.

  • While TAdsConnections are not strictly required, I would strongly urge you to use them in your code.  If we had a chance to do it over again, we would require connections.  Initially you should be able to use a single connection for all tables, subdirectory\tablename.dbf also works for locating tables. If you do not provide a connection, one will be created for you in ACE; however, you it will be more difficult to control that connection since you don't have the TAdsConnection wrapper around it.  This makes getting exclusive access to tables more difficult.  Checkout the GExpert components, they have a good way of replacing components and adding properties, like a TAdsConnection.

    All database access is syncronized at the connection level.  Consider two TAdsTables are opened on the same connection, but by two different threads. When the threads attempt to skip through the tables each thread would block when calling any ACE API.  If each thread used it's own connection, they would only block when trying to use a shared resource.  In general any time you create a thread, you should create a uniquely named TAdsConnection for it to use.

  • 1.  Use a data dictionary.  It is has the capability to be able to store a relative path to a table.  So it would be able to locate tables no matter what subdirectory they are in.

    2.  Use as many connections, to as many subdirectories as you need. The server can support 64k of them, and as long as you don't leak them then I strongly doubt you will run out.

    If you are opening the tables as Visual FoxPro, ADS_VFP, style tables then we need the adscollate to correctly determine the language to use.  In general you can't go wrong shipping all the files in the redistribute directory.

    A final note, while Advantage Local Server will reduce corruption, only Advantage Remote Server will be able to virtually elmininate it.

  • It should not generally be a problem to use multiple connections particularly if it makes it easier to access tables in different folders.  However, one potential issue with the idea of one connection per table is that multiple tables could not be updated in the same transaction. (http://devzone.advantagedatabase.com/dz/webhelp/Advantage11/master_transaction_processing_system.htm). Transactions are not supported with local server, so it is not really an issue there, but if you do move to remote server and end up using transactions, it could be something to consider.  A single transaction is specific to a connection.  If you wanted to update two tables in the same transaction, then they would both have to be opened and updated on the same connection.

    As far as multi-threading goes, it is quite possible you may never have to deal with it.  Many (most?) user-oriented applications may never need more than one thread (from the developer's perspective).  One situation that might benefit from using multiple (two) threads is if you have an SQL query that can be fired off by a user that is lengthy (e.g., maybe for some report), running it on a separate thread can be nice because it allows the user to still interact with the application while the other thread is waiting for the query to finish.  If the lengthy query were executed on the "main" thread, the application would not be responsive until the query finished (and this is sometimes "solved" by simply changing the cursor to an hour glass to let the user know a wait is expected).  If you install Advantage Data Architect, you can maybe see an example of how this works. The SQL utility in that application executes queries on a separate thread. You can hit the button to execute a query and then still do other things in the application (including cancelling the query).  Of course, in order to observe that behavior you would need a long running query.

No comments