Server design (multithreading, serialization, and performance)

Question

(I'm not asking for anyone to design my software for me, I'm just looking for a response along the lines of "That's called XYZ server design, look for books on this topic" sort of thing.)
Summary:
I have a Server application (S) that accepts connections from many Clients (C). The clients request pieces of a large internal data structure, *"Data"* (D). The clients are totally passive with respect to Data, they only read (from the Server) and do not initiate any modification.
D is really a structure of structures: it's hashtables of hashtables, with objects that hold other hashtables and vectors, etc. etc., down a few levels. The clients don't read the entire structure, just parts of it.
The Server is multi-threaded, with threads handling client communications, and a very important thread that modifies Data by processing messages from an external source. I call this part of the software the Message Processor (P). These messages are what drives manipulation of the data structure.
[**CLICK HERE FOR A DIAGRAM**|http://imgur.com/sb5ZU]
There are a couple of design questions I'm wondering about:
The data structure D is a shared resource between the Client threads and the Message Processor thread within the Server, with the Client threads only reading from the data structure (and writing over TCP/IP), and the Message Processor both reading and modifying it.
Right now I am using locks to lock the structure when a client requests data, so that the processor cannot modify the data while it is being serialized.
I also lock the data structure when a message is received and the structure has to be modified by P, to prevent the structure from being serialized while it is being modified.
My question is, is this the only design pattern I can use in this situation? It looks like the only way to improve performance is to
a) make sure I only lock when necessary (to prevent data corruption or inconsistency)
b) lock the data for as short a time as possible
c) make sure the parts of the data structure being sent to clients are serialized as fast as possible (write my own writeObject/readObject methods)
Any insight is appreciated, the shorter and more candid, the better. Don't be afraid to say I'm in over my head and should read a few books by author so-and-so, that's a good starting point :)

Answer 1

jta23 wrote:
(I'm not asking for anyone to design my software for me, I'm just looking for a response along the lines of "That's called XYZ server design, look for books on this topic" sort of thing.)
Summary:
I have a Server application (S) that accepts connections from many Clients (C). The clients request pieces of a large internal data structure, *"Data"* (D). The clients are totally passive with respect to Data, they only read (from the Server) and do not initiate any modification.
Are you using Servlets? That should facilitate the development of your server immensely (e.g., maintains sessions, handles multi-threading, implements HTTP out of the box, dozens of additional frameworks available, etc.)
D is really a structure of structures: it's hashtables of hashtables, with objects that hold other hashtables and vectors, etc. etc., down a few levels. The clients don't read the entire structure, just parts of it.
You can get away with using Map of Map or Map of List or whatever level of nesting you want. Generally, however, it is better to implement a canonical and rich domain model. [http://www.eaipatterns.com/CanonicalDataModel.html]. [http://www.substanceofcode.com/2007/01/17/from-anemic-to-rich-domain-model/].
The Server is multi-threaded, with threads handling client communications, and a very important thread that modifies Data by processing messages from an external source. I call this part of the software the Message Processor (P). These messages are what drives manipulation of the data structure.
[**CLICK HERE FOR A DIAGRAM**|http://imgur.com/sb5ZU]
There are a couple of design questions I'm wondering about:
The data structure D is a shared resource between the Client threads and the Message Processor thread within the Server, with the Client threads only reading from the data structure (and writing over TCP/IP), and the Message Processor both reading and modifying it.
Right now I am using locks to lock the structure when a client requests data, so that the processor cannot modify the data while it is being serialized.
I also lock the data structure when a message is received and the structure has to be modified by P, to prevent the structure from being serialized while it is being modified.
My question is, is this the only design pattern I can use in this situation? It looks like the only way to improve performance is to
a) make sure I only lock when necessary (to prevent data corruption or inconsistency)This can easily be handled by a Servlet. I think the best way to do this would be to create a Singleton. [www.javacoffeebreak.com/articles/designpatterns/index.html]. Be careful, however. Singletons are like global variables. They can easily be abused. If you did not want a singleton, create a lock table in your database. The RDBMS will handle synchronization for you, and it is an elegant solution. You can perform a similar feat using a filesystem lock that you create. Up to you. Whether in the JVM, in the database or in the filesystem.
b) lock the data for as short a time as possibleWrite an efficient method to insert or update or delete the data. If you are dealing with a large amount of data, consider using a native tool like Oracle's SqlLoader or using vendor-specific JDBC syntax. If you need to support multiple types of databases, use bulk JDBC operations.
c) make sure the parts of the data structure being sent to clients are serialized as fast as possible (write my own writeObject/readObject methods)
Take a look at JBoss serialization. It is much more compact that Java's. Or do some experimenting. JSON is much more compact than XML normally, and it can be read by a Javascript client to facilitate any Ajax you might want to use for some flash and sizzle.
Any insight is appreciated, the shorter and more candid, the better. Don't be afraid to say I'm in over my head and should read a few books by author so-and-so, that's a good starting point :)No, take it in bite sized pieces. Start with the server. Then work on the client. Play around with your locking strategy. Optimize your update of the data. Don't do everything at once.
- Saish