id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
36551	Race condition in savepoint ID generation causes duplicate identifiers	Mijo Kristo		"**Problem**

The BaseDatabaseWrapper.savepoint() method contains a race condition where the operation self.savepoint_state += 1 is not atomic. This can lead to duplicate savepoint IDs in multithreaded environments.

**Location**

django/db/backends/base/base.py, line ~608

**Problematic Code**
{{{
thread_ident = _thread.get_ident()
tid = str(thread_ident).replace(""-"", """")

self.savepoint_state += 1  # Race condition here
sid = ""s%s_x%d"" % (tid, self.savepoint_state)
}}}

**Impact**

- Multiple threads can read the same savepoint_state value
- Results in duplicate savepoint IDs (e.g., ""s123_x5"", ""s123_x5"")
- Causes database errors when rolling back to savepoints
- Can lead to data corruption in high-concurrency applications
- Affects applications using nested transaction.atomic() blocks

**Reproduction**

The race condition can be reproduced with this simple test:
{{{#!python
import threading, time

counter = 0

def buggy_increment():
    global counter
    temp = counter
    time.sleep(0.001)
    counter = temp + 1
    print(f'Thread got: {counter}')

threads = [threading.Thread(target=buggy_increment) for _ in range(5)]
for t in threads: t.start()
for t in threads: t.join()

print(f'Final: {counter} (should be 5)')
}}}

Expected output: Final: 5
Actual output: Final: 1 (lost updates due to race condition)

**Real-world scenarios**

This bug can manifest in production applications as:
- ""savepoint does not exist"" database errors
- Transaction rollback failures
- Silent data corruption in e-commerce/banking applications
- Inventory overselling in high-traffic scenarios

**Proposed Fix **

Wrap the increment operation in the existing _thread_sharing_lock:
{{{#!python
thread_ident = _thread.get_ident()
tid = str(thread_ident).replace(""-"", """")

with self._thread_sharing_lock:
    self.savepoint_state += 1
    sid = ""s%s_x%d"" % (tid, self.savepoint_state)
}}}
This solution:
- Uses Django's existing thread safety infrastructure
- Has minimal performance impact
- Maintains backward compatibility
- Fixes the race condition completely

**Testing**

The fix can be verified by running the reproduction case above - with the fix, all threads will get unique values.

Django's existing test suite should continue to pass as this change only affects the thread safety of savepoint generation without changing the API.

**Additional Notes**

- This is an ideal ""easy pickings"" issue for new contributors
- The bug is timing-dependent and may not reproduce consistently
- High-concurrency production environments are most affected
- The fix leverages existing Django patterns for thread safety"	Bug	new	Database layer (models, ORM)		Normal		threading savepoint race condition thread safety		Unreviewed	0	0	0	0	0	0