Thanks for the response Andrew, I'm afraid I can't have put myself well, I understand the points you make.
The thing I want to get straight is really a performance one rather than a logical one. I know performance isn't out concern, but I'd like to get it straight anyway.
The points you make aside, the reason we lock on the record as opposed to the whole database is a performance one. Access to the data is synchronised, since there is just one source of data. This is ultimately where all threads converge. So this is likely the bottleneck. The fact that a record is locked is immaterial because if the client wants to update then the operation to do that at the back end locks the whole database.
I realise the point of multithreading is that everything else can be completed in tandem, but at the end they must all queue up and take there turn at the data.
I guess this is the 1st time I've rubbed my nose in the mechanics, and before (
JDBC / Access etc) The notion of a record lock meant minimising resource restrictions.
The answer I'd like now would be something like: the actual RAF operations are actually lightening fast and all the other stuff that is done multithreaded does actually take most of the time.
Or maybe this has revealed a major flaw in my thinking. Please put me straight!
TIA