It depends largely on your topology (Is the web-server on the same machine as the database? If not, how fast is the network? What is the distance between the machines?); the machine (I/O configuration? Disk speed? Processor speed? Memory?); the database (Vendor? Version? Load? Transaction log enabled? Replicating?); the driver (JDBC level? Thin?) and the efficiency of your code. I don't think it's something you can calculate beforehand...you have to implement a test case and benchmark it under a load to see how much wiggle room you have.
You would be loading a POJO, updating a property, and flushing the session 50 times per second. If you had to load the POJO each time (new session for each count) then that's a 100 transactions per second (SELECT + UPDATE). If you load the POJO once, and cache it as a detached object in some kind of singleton instance then you only have the updates. It's probably in the realm of possibility, but it would be more efficient to flush periodically (once every 50 counts, or once per second, for example). The trade-off there would be that if a transaction were to fail (the DB crashes or you get a StaleObjectException, for example) you would lose about 50 counts. If that's not acceptable, then a periodic flush may not be feasible.
- Jesse
|