Sam, in my experience, tables and cursors opened within an MTDLL will remain open within that MTDLL's thread-local storage unless the object type that is instantiated is of type SESSION with private datasessions being used. I've experimented extensively with this and results are consistent. That is, if an object of (for example) class CUSTOM opens a table, that table will remain open (file handle remains alive) within the thread in which the object lived even after the object itself is destroyed. Same thing with cursors. It's like one person walking away from a PC running a VFP app, and another person coming by and sitting there and using that same running app... tables will already be open and in same state as last user left them. With an MTDLL, as long as the thread itself is not terminated, those tables/cursors remain open unless explicitly closed by the VFP code. However, if an object is of class SESSION and (importantly) if private datasessions are used, then all tables/cursors that were opened by that object are implicitly closed when the object is destroyed.

Bottom line is that unless private data sessions are used for each object, then the folowing unwanted scenario can potentially happen: Keep in mind that two or more objects of the same class can coexist on the same thread. Each object runs on that thread with serialized (i.e., uninterrupted) calls to its methods. This means that when a method is running, it won't be interrupted by another object on the same thread. Another object's (object B's) method will not be called until the executing method from object A returns control back to the caller. However, the lives of the objects on the thread are not serialized, only calls to their methods are serialized. Thus there is a real-life chance that a cursor created by a method in object A can be overwritten by a method in object B, then re-accessed by a later call (on same ASP page) to another method in object A with object A getting incorrect data. This is because calls to the 2 objects' method can potentially be interleaved. This scenario of object-walking-on-another-object-on-the-same-thread probably won't show up until the server is busy and all threads that ASP intended to allocate for the MTDLL are actually running (is it 10 or so?), and then ASP starts creating multiple objects on the same thread.


>Hi Mark,
>
>You've probably already figured this out, but each instance of a MTDLL creates its own independent environment regardless of the underlying object type so there should be little problem managing concurrencies. One 'best' practice would be to condition updates on a primary key and datestamp. Obviously, the only reason you'd want to use the VFP Session as the underlying object in a web environment would be to access the inherited props/events/methods.