I have an app which will generate 5 – 10 new database records in one host each second.
The records don’t need any checks. They just have to be recorded in a remote database.
I’m using Java for the client app.
The database is behind a server.
The sending data can’t make the app wait. So probably sending each single record to the remote server, at least synchronously, it’s not good.
Sending data must not fail. My app doesn’t need an answer from the server, but it has to be 100% secure that it arrives at the server correctly (which should be guaranteed using for example http url connection (TCP) …?).
I thought about few approaches for this:
-
Run the send data code in separate thread.
-
Store the data only in memory and send to database after certain count.
-
Store the data in a local database and send / pulled by the server by request.
All of this makes sense, but I’m a noob on this, and maybe there’s some standard approach which I’m missing and makes things easier. Not sure about way to go.
Your requirements aren’t very clear. My best answer is to go through your question, and try to point you in the right direction on a point-by-point basis.
How exactly are you planning on the client knowing that the data was received without sending a response? You should always plan to write exception handling into your app, and deal with a situation where the client’s connection, or the data it sends, is dropped for some reason. These two statements you’ve made seem to be in conflict with one another; you don’t need a response, but you need to know that the data arrives? Is your app going to use a crystal ball to devine confirmation of the data being received (if so, please send me such a crystal ball – I’d like to use it to short the stock market).
Ok, so it sounds like you want non-blocking I/O. But the reality is, even with non-blocking I/O it still takes some amount of time to actually send the data. My question is, why are you asking for non-blocking and/or fast I/O? If data transfers were simply extremely fast, would it really matter if it wasn’t also non-blocking? This is a design decision on your part, but it’s not clear from your question why you need this, so I’m just throwing it out there.
As far as putting the data in memory and sending it later, that’s not really non-blocking, or multi-tasking; that’s just putting off the work until some future time. I consider that software procrastination. This method doesn’t reduce the amount of time or work your app needs to do in order to process that data, it just puts it off to some future date. This doesn’t gain you anything unless there’s some benefit to “batching” data sending into large chunks.
The in-memory idea also sounds like a temporary buffer. Many of the I/O stream implementations are going to have a buffer built in, as well as the buffer on your network card, as well as the buffer on your router, etc., etc. Adding another buffer in your code doesn’t seem to make any sense on the surface, unless you can justify why you think this will help. That is, what actual, experienced problem are you trying to solve by introducing a buffer? Also, depending on how you’re sending this data (i.e. which network I/O classes you choose) you might get non-blocking I/O included as part of the class implementation.
Next, as for sending the data on a separate thread, that’s fine if you need non-blocking I/O, but (1) you need to justify why that’s a good idea in terms of the design of your software before you go down that route, because it adds complication to your app, so unless it solves a specific, real problem (i.e. you have a UI in your app that shouldn’t get frozen/unresponsive due to pending I/O operations), then it’s just added complication and you won’t get any added performance out of it. (2) There’s a common temptation to use threads to, again, basically procrastinate work. Putting the work off onto another thread doesn’t reduce the total amount of work needing to be done, or the total amount of I/O your app will consume in order to accomplish its function – it just puts it off on another thread. There are times when this is highly beneficial, and maybe it’s the right decision for your app, but from your description I see a lot of requested features, but not the justification (or explanation of the problem you’re trying to solve) that backup these feature/design choices, which is what should ultimately drive the direction you choose to go.
Finally, as far as having the server “pull” it instead of it being pushed to the server, well, all you’re doing here is flipping the roles, and making the server act as a client, and the client the server. Realize that “client” and “server” are relative terms, and the server is the thing that’s providing the service. Simply flipping the roles around doesn’t really change anything – it just flips the client/server roles from one part of the software to the other. The labels themselves are just that – labels – a convenient way to know which piece is providing the service, and which piece is consuming the service (the client).
This shouldn’t be a problem. Any decent DB server will treat this sort of work as extremely low load. The bigger concern in terms of speed/responsiveness from the server will be things like network latency (assuming you’re transferring this data over a network) and other factors regarding your I/O choices that will affect whether or not you can write 5-10 records per second – that is, your overall throughput.