Try it for your benchmarks. If it turns out to be significantly faster, you can probably figure out a protocol to let you use that nearly all the time, and fall back to something slower if you need to. For example, if you use the ip as the primary key and rows are never deleted, you can:
in reply to Re^4: Multiple write locking for BerkeleyDB
in thread Multiple write locking for BerkeleyDB
- Try the update. If one row is affected, you are done.
- Otherwise, the row does not exist. Try an insert. If it succeeds, you are done.
- Otherwise, if it failed with a duplicate key, somebody else just inserted it. Retry the update.
- If the update fails again, something is wrong, so give up.