Skip to content

fix race conditions in transaction handling#87

Open
maxbachmann wants to merge 1 commit intostrichliste:masterfrom
maxbachmann:patch-3
Open

fix race conditions in transaction handling#87
maxbachmann wants to merge 1 commit intostrichliste:masterfrom
maxbachmann:patch-3

Conversation

@maxbachmann
Copy link
Contributor

@maxbachmann maxbachmann commented Oct 6, 2025

This is a more complete version of #86. Take this with a grain of salt since I am no php programmer and not regularly working with dbs as well:

The change set does:

  • check whether transaction was already deleted after locking the row (probably the most important fix)
  • locks involved transactions, users and articles. This could absolutely require someone more knowledgeable to double check so they are actually required in these cases
  • locks are pulled in a consistent order transaction -> user -> action. If there are multiple they are ordered by their id

Still broken is:

  • undo of a transaction that involves an article that is no longer active because it was modified. In this case the usage count isn't updated for the newer revisions and so breaks them.
  • barcode unique check races with the actual insert if it's added at the same time. (The user name check as well, but that is marked as unique in the dB and so should be catched there)

@maxbachmann
Copy link
Contributor Author

I did see there is new work happening in https://github.com/foosinn/strichliste/tree/main

What is the state of this? The current version of both the backend and frontend doesn't build/run on my development machine anymore. It looks like at least PHP 8.4 is supported there.

$sender = null;
$recipient = null;
if ($recipientId) {
if ($senderId < $recipientId) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm.... that senderId < recipientId doesnt make much sense, right? :D Why shoild that influence the order of getting the sender and recipient?

Copy link
Contributor Author

@maxbachmann maxbachmann Oct 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the same as the id sort in the revert and done for running:

doTransaction(user1, ..., user2):
and
doTransaction(user2, ..., user1):

at the same time. When locking both user1 and user2 without the ordering this could lead to a deadlock where
the first call locks user1 and the second call locks user2. Both wouldn't be able to lock the other user.

By sorting the users by their id you get a defined locking order that prevents this deadlock.

@schinken
Copy link
Contributor

schinken commented Oct 6, 2025

I did see there is new work happening in https://github.com/foosinn/strichliste/tree/main

What is the state of this? The current version of both the backend and frontend doesn't build/run on my development machine anymore. It looks like at least PHP 8.4 is supported there.

We started working on making strichliste compatible with php8.x and also updating symfony to the latest version. additionally there is a docker container with frankenphp.

but it's all WIP

@maxbachmann maxbachmann force-pushed the patch-3 branch 2 times, most recently from 874cd14 to 55a7ae9 Compare October 6, 2025 10:43
Comment on lines +189 to +203
$transactions = [];
foreach ($transactionIds as $id) {
$trans = $this->entityManager->getRepository(Transaction::class)->find($id, LockMode::PESSIMISTIC_WRITE);
if (!$trans) {
throw new TransactionNotFoundException($id);
}

$transactions[] = $trans;
}

foreach ($useIds as $id) {
$user = $this->entityManager->getRepository(User::class)->find($id, LockMode::PESSIMISTIC_WRITE);
if (!$user) {
throw new UserNotFoundException($id);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume you could combine those in less sql queries to make things faster. Not that it likely matters all that much for this project.

@maxbachmann
Copy link
Contributor Author

This is now also roughly tested so it doesn't immediately fall apart. The error paths aren't tested.

@maxbachmann
Copy link
Contributor Author

maxbachmann commented Oct 6, 2025

We started working on making strichliste compatible with php8.x and also updating symfony to the latest version. additionally there is a docker container with frankenphp.
but it's all WIP

We are currently planning to redo our setup for a couple of reasons:

  • somewhat corrupted db due to the incorrect transaction changes
  • we still have a native setup and want to move it into containers
  • there is some other unclear breakage that leads to not being able to run the command line so we can't reload the settings to adjust prices (is there a reason not to always reload the settings on a restart). Really that one is probably because someone thought it was a good idea to play around in the code base of the life installation ...
  • our backups are currently still a manual process and so not done very often
  • while doing the work anyway we maybe wanted to look into some things in the frontend we aren't completely happy with

While working on this I noticed that nothing runs on fedora 42 anymore:

  • backend -> no php 8.4 support
  • frontent could be worked around using NODE_OPTIONS=--openssl-legacy-provider yarn build

Is there any expected time frame for the 8.4 changes whether it's worth waiting for them or setting up a docker with an old php version?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants