Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

A PageFileConfig built with an object initializer gets LockTimeout.Immediate: every lock fails at once under contention

Open
  • Is something wrong?
#322 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
databases

Research direction

Start with PageFileConfig.Normalize() and the LockTimeout type and property; the issue names no source or test files, so first locate those definitions and the tests for partial configs and concurrent inserts. Compare an object-initialized config with PageFileConfig.Default under the reported workload. Done when an unset timeout uses the intended default, explicit Immediate remains usable, and the contention case no longer fails as reported.

Written by the indexing model from the issue text.

Description

bug package/core severity/medium

What happens

A PageFileConfig built with an object initializer, for example new PageFileConfig { AllowMultiProcessAccess = true } (the pattern the Normalize() doc comment uses as its example), opens with LockTimeout(Read=0ms, Write=0ms, MaxWriters=0), which is LockTimeout.Immediate. Every lock then fails at once under any contention.

Normalize() fills in PageSize and GrowthBlockSize from Default, but not LockTimeout. default(LockTimeout) has the same value as LockTimeout.Immediate, so the engine cannot tell "not set" from "fail fast on purpose".

Measured on main (0450b97): new BLiteEngine(path, new PageFileConfig { AllowMultiProcessAccess = false }), then 4 tasks × 50 auto-committing InsertAsync on one collection: 150 of 200 inserts throw TimeoutException. The same workload with PageFileConfig.Default throws none.

Why it matters

  • The doc comment on PageFileConfig.LockTimeout says it defaults to LockTimeout.Default. That is true only for the presets (Small, Default, Large, Server, DetectFromFile).
  • Normalize() says it makes "a partially-constructed PageFileConfig ... always valid", and its example config gets fail-fast locks.
  • It is the strongest form of #303: a healthy database that rejects most concurrent writes.

Possible fixes

  1. Give LockTimeout a hidden "was set" flag (set by Immediate, Default, From and the init accessors), and have Normalize() replace an unset value with LockTimeout.Default. Equality stays on the three values.
  2. Or make Immediate distinguishable from default some other way, and document that default(LockTimeout) means "use the default".
  3. At minimum, correct the two doc comments so they say that an initializer without LockTimeout gets Immediate.

Connected

  • #303 / PR #321: LockTimeout.Default 500 ms → 5 s. #321 does not change this case: a partial config still gets 0 ms.
  • #288 (reliability epic).
Dominant language
C#
Stars
66
Forks
6
Avg merge
1d 2h
Merged PRs (30d)
58

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EntglDb/BLite

All issues in EntglDb/BLite

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.