2

Does hibernate that utilises connection pools require retries to take care of intermittent failures (e.g. network issues). My colleague is of the opinion that it's not necessary cause of the use of connection pools and that if there was anything wrong with the connection then the connection pool manager would take care of it. I'm not convinced as the connection could be open and valid, but when the request is made it could succumb to network issues.

As what is being done is related to payments we need strong guarantees that the update takes place. I tried googling how hibernate/connection pools might deal with intermittent issues during a single request but couldn't find much information.

The entity is being saved by a call to getSession().update(object); where getSession() returns the current Hibernate session. We use Hibernate v4.3 and looking at the hibernate documentation it only mentions an exception is thrown if the persistence instance has the same identifier.

Would appreciate if I could get some links to some references/documentation that might guide my confusion.

n00b
  • 5,843
  • 11
  • 52
  • 82

1 Answers1

0

You should rely on transactions to give you strong guarantees that a change is made atomically. So in case of a (network) failure your transaction would rollback.

Connection pools provide no such functionality, they facilitate the reuse of connections. See this question about connection pooling: What is database pooling?

Chris
  • 958
  • 8
  • 19
  • Thanks. The request is made within a transaction so I'm not so concerned about the changes being atomic. I'm more concerned about ensuring the update takes place and is guaranteed (which we will probably enforce via a queue). – n00b May 09 '18 at 09:57
  • 1
    There is no way for either the pool or Hibernate to "retry". For example, if PreparedStatements had been prepared and values set, if the Connection becomes invalid, there is no way for the pool or Hibernate to know how to "replay" those actions on a new connection. – brettw May 09 '18 at 20:11
  • 1
    Making a truly fault-tolerant system for financial transactions is *extremely* difficult. If you queue in memory and retry on DB failure, a power loss will still lose the xaction. If you spool to a local xaction file, what happens if the system crashes in the middle of a write, before the data is flushed to the disk? Hardened systems use redundancy, including battery-backed disk controllers that can run long enough to flush data on pwr failure. If this is really a financial app, you need to do a *lot* of research, or you are headed for disaster, eventually. Rule#1: Systems Fail. – brettw May 09 '18 at 20:16
  • Thanks @brettw that's what I assumed and so will code accordingly. – n00b May 15 '18 at 04:22