> I'll be interested to see what your results are. If the two servers are running on the same machine they'll still be sharing the same resources. What is different is that Windows/you can set the priorities for each process (I think) so you might be able to "improve" matters that way.

True - but I figure because it isn't the same 'process' - it may stop
users from being locked out, etc.

Good thought on setting different priorities too - that's worth keeping
in the back of my mind.

Cheers

Adam.

Adam

>True - but I figure because it isn't the same 'process' - it may stop
>users from being locked out, etc.

Don't think it will work like that. You mentioned that these queries are updating data so it will be DBISAM locking and that won't be affected by running a separate instance of the server.

I'm assuming that you're using a transaction for these queries, however, a thought went through my mind. What's probably happening is that you're setting write locks against the tables. If there's a lot of processing to generate the data to do the write you could be extending the life of the lock. How about altering the query to write the results to a temporary table, no write locks on the main table for that, and then use the temporary table to update the main tables?

Roy Lambert [Team Elevate]

Adam,

<< The one particular user is running some queries that are taking some time
to chew through the data. (Minutes). During this time, it's causing other
users to work quite sluggish, and in some cases time out. >>

What is timing out ?  Locks ?  If so, then your issue is locking-related and
not processor/disk-usage related.  It also means that something during the
processing is holding either a read lock or a transaction lock (the only two
types of locks that can be held for a while) for too long.

Tim Young
Elevate Software
www.elevatesoft.com

Hi Roy,

>> True - but I figure because it isn't the same 'process' - it may stop
>> users from being locked out, etc.
>
> Don't think it will work like that. You mentioned that these queries are updating data so it will be DBISAM locking and that won't be affected by running a separate instance of the server.
>
> I'm assuming that you're using a transaction for these queries, however, a thought went through my mind. What's probably happening is that you're setting write locks against the tables. If there's a lot of processing to generate the data to do the write you could be extending the life of the lock. How about altering the query to write the results to a temporary table, no write locks on the main table for that, and then use the temporary table to update the main tables?

Thanks for your reply. I agree with your current assessment regarding
transactions, however I think for parts of the process where
transactions aren't in place this may still work?

I'm not a thread expert - it takes me ages to get one to go through the
eye of a needle but I guess if DBSRVR is using a separate thread /
session per connected user, then this may not make any difference.

I guess I'm unsure of how DBSRVR is designed, and whether or not one
user doing a nasty query would cause issues for other users connecting
to the same DBSRVR instance or not.

Cheers

Adam.

Hi Tim,

Thanks for your reply.

> << The one particular user is running some queries that are taking some
> time to chew through the data. (Minutes). During this time, it's causing
> other users to work quite sluggish, and in some cases time out. >>
>
> What is timing out ?  Locks ?  If so, then your issue is locking-related
> and not processor/disk-usage related.  It also means that something
> during the processing is holding either a read lock or a transaction
> lock (the only two types of locks that can be held for a while) for too
> long.

At this stage, it seems as though it's just timing out whilst waiting to
get a response back from the server. (ie, from what users are telling
me, even when the application isn't even trying to write to files, just
loading some data).

I'll have to investigate a little more. Most of the transactions I have
within the application are pretty 'quick'. It seem as though the issue
may lie with the amount of work required to retrieve some results.

Before going too far, I just wanted to make sure there wasn't anything
simple that I was missing.

Cheers

Adam

Adam


>Thanks for your reply. I agree with your current assessment regarding
>transactions, however I think for parts of the process where
>transactions aren't in place this may still work?

My bet is it will be no different to running a single instance of the server, possibly apart from context switching.

>I'm not a thread expert - it takes me ages to get one to go through the
>eye of a needle but I guess if DBSRVR is using a separate thread /
>session per connected user, then this may not make any difference.

I think there's a smidgeon of a difference in context switching for threads vs processes but I'm not sure what.

>I guess I'm unsure of how DBSRVR is designed, and whether or not one
>user doing a nasty query would cause issues for other users connecting
>to the same DBSRVR instance or not.

I'm not sure either, I've never had a need to investigate its internals, but unless Tim does all the context switching himself he has the options of using threads or spawning multiple processes and I've never seen any evidence for the latter.

Roy Lambert [Team Elevate]