Hacker News new | ask | show | jobs
by mike_hearn 405 days ago
If it's configurable that's very new. It definitely has been hard coded and unconfigurable by design the entire history of the project that I've known it. They just tell you to work around it, not tweak it for your app.

Transactions holding locks for too long are indeed a problem though in Oracle transactions can have priorities and steal each other's locks.
1 comments
Dave_Rosenthal 404 days ago
It looks like it might be knobs (which can be changed via config file) called MAX_WRITE_TRANSACTION_LIFE_VERSIONS and MAX_READ_TRANSACTION_LIFE_VERSIONS now (defined in ServerKnobs.cpp)? It's in microseconds and probably needs to be synced client and server.

I don't know the details know, but it was definitely configurable when I wrote it :) I remember arguing for setting it to a default of 30/60 seconds we decided against as that would have impacted throughput at our default RAM budget. I thought might have been a good tradeoff to get people going, thinking they could tune it down (or up the RAM) if they needed to scale up perf later.

link
mike_hearn 404 days ago
Hah, well I'll defer to your knowledge then :) I don't remember seeing any kind of negotiation protocol between client and server to find out what the timeout is, which would be needed for it to be properly configurable. But it could be easily added I guess. I admit I never understood why changing it wasn't a proper feature.
link