Apollo SDE API Threading (Examples and Explanation) Vista Software www.vistasoftware.

com -----------------------------------------------------------------------------Apollo is a suite of This API is the core and writing the data engine. All three of manage threading. data engine that wrap the underlying Apollo SDE API. of data management engine responsible for reading files. There are over 150 functions in this core these examples use this Apollo SDE API directly to

More information can be found here: http://www.vistasoftware.com/sde_spec.asp -----------------------------------------------------------------------------Examples: -----------------------------------------------------------------------------OnlyWayToWork ---------------------OnlyWayToWork.dpr is an example of how to do threading correctly with Apollo and its SDE API. Basically, it reopens tables in new threads. The advantage to this approach is that you most likely won't run out of workarea space (254 per thread). The disadvantage is, you use a bit more memory for the thread space. Not likely an issue, however. Method65025 ---------------------Method65025.dpr is an example of using the sx_SysProp(65025, Pointer(1)); BadWayToThread ---------------------This demonstrates how not to do threading. BadWayToThread.dpr is an example of trying to share WorkAreas between threads. Notice the 3200 errors. In this BadWayToThread example, Adding a simple SysProp call to right before doing any work with tables lets you share work areas without any errors or problem at all. The disadvantage in doing this is that in any complex application you might run out of work areas fairly quickly.

-----------------------------------------------------------------------------Overview -----------------------------------------------------------------------------This is an overview of the technique used by the SDE for multithreading processing. Every thread accessing the SDE engine can use a 254 workarea spool. These spools are independent from each other. So, if you open a table in one thread, respective workarea's context (work area identifier, aliases, record pointer, different flags and so on) do not carry over to another thread. In this way, you can access 254 independent tables, multiplied by the number of threads. DBF tables can be shared between threads only at READONLY or READWRITE modes just like you access DBF tables from different applications.

So, we can think of a single 254 workarea spool as a unique session happening in a unique thread. If a thread terminates, you cannot access the respective workarea spool. Also, you have to 'close' tables carefully before the thread terminates. The API is shielded internally by Win API critical sections. This ensures the safest environment for multithreading while user applications access the SDE API. This also excludes deadlocks unless you use callbacks for error reporting, in this case, deadlocks could exist. This design allows you to build multithreaded applications without any additional programming. The referenced 65025 property could useless for multithreading tasks unless you don't have a way of managing threads correctly. The aim of this 65025 property is to switch the SDE into a single 254 workarea spool that is shared between threads. But with this setting, you becomes responsible for managing the sharing of workarea context between threads. (i.e. you have to call the correct sx_ API functions from different threads in order to get the correct results.) Basically, this means that you would have to design your own synchronization mechanism with WinAPI kernel objects. Finally, if you are creating a DLL that works with Apollo, the SDE must be loaded from your DLL so that you initialize the correction sx_ functions. -----------------------------------------------------------(c) 1999-2002. ) Vista Software. All rights reserved.