ServerSocket and the need for critical sections

I’m working on a project that uses a ServerSocket populated with instances of a SecureSocket subclass. The subclass instances write to an application-global SQLite database.

I know that when writing to a database in a multi-threaded context, I should use a semaphore or criticalSection to prevent multiple threads from accessing the same resource at the same time. Do I also need to do this when accessing the database from multiple sockets, or are they all running on the same thread?

Writing to a db is one of those spots where YOU probably don’t need to use critical sections. In fact f you are you’re probably causing more delay than you need. That’s the point of a db - the ability to serialize things across multiple readers / writers.

Just don’t use the same connection across all the threads. Thats asking for problems.
Reading is fine from multiple thread an you do not need to block other readers.

See question #5 http://sqlite.org/faq.html

Thanks for replying Norman. My confusion has to do with whether each of my ServerSocket’s instance sockets is running on the main thread, or on its own thread. This app is using an SQLite database, not a database server. My app IS the server.

Is it possible that without a criticalSection/Semaphore, one of my sockets might step on another’s attempt to write to the global db connection?

I am not using a criticalSection or semaphore, but am wondering whether I should be…

[quote=149503:@Peter Truskier]Thanks for replying Norman. My confusion has to do with whether each of my ServerSocket’s instance sockets is running on the main thread, or on its own thread. This app is using an SQLite database, not a database server. My app IS the server.
[/quote]
SQLite still manages multiple connections appropriately as far as locking readers / writers goes.
So even if all you do is have each instance have a separate db connection your going to not have to worry too much about reader / writer contention.
Thats why I pointed you to the Sqlite FAQ’s.
Sockets aren’t “threads” BUT if you write things as if they were (subclass etc that has its own db connection etc) then you should be fine.

If you don’t & you use a shared connection across all sockets then you will have to manage access with a critical section.

If your code is in the sockets events, then it is executing in the main thread and your writes will happen consecutively. That’s why you should keep the code in the events short. Get in and get out and let the next event fire.

I do have a server running, (100 simultaneous users) with a similar architecture using regular TCPsockets. After a lot of trials using semaphores I did solve my problems simply using a single global method to do all the writes. I assume Xojo/Real Studio is not reentrant, and the writing method calling SQLite by itself will not allow any other socket call write before SQLite has finished the previous command.

In general, that is true.

Thank you all for your input…