Forum Stats

  • 3,769,982 Users
  • 2,253,043 Discussions


Transaction across threads

530173 Member Posts: 2
edited Aug 26, 2006 9:00AM in Berkeley DB Java Edition

Is it safe to distribute a single transaction across multiple threads? Currently, I have a single thread performing adds/deletes/updates to the db in a single monolithic transaction. This pretty much tops out at about 4-5k/sec. Using multiple writer threads to perform the same operations by dividing them up as jobs across threads while using the same transaction.. is this a feasible idea? If so, what performance improvements can I expect?



  • Charles Lamb
    Charles Lamb Member Posts: 836
    Hi Nikunj,

    Yes, you may use a transaction across multiple threads. The place where we synchronize is on lock acquistiion (and lock release at commit time). Your performance will depend on the number of processors and how distributed the keys are (i.e. if you're not operating on conflicting keys in the same transaction then you'll get better concurrency). If the lock table becomes a bottleneck, we have a parameter, je.lock.nLockTables that can be used to split the lock table into multiple lock tables. The doc says:

    Number of Lock Tables. Set this to a value other than 1 when
    an application has multiple threads performing concurrent JE
    operations. It should be set to a prime number, and in general
    not higher than the number of application threads performing JE

    You may hit serialization issues on the Transaction object before you do on the lock table.

    Charles Lamb
  • Just for reference, the JE FAQ has moved to a new home on the Oracle website, and an item on locking configurations can be found here:

    It mentions no-locking mode, and the lock table configuration already described by Charles, so there's no additional information that applies, but some of the other entries might be of interest, and we'll add more to over time.


This discussion has been closed.