New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating last_login_at
leads to deadlocks
#207
Comments
Would like to add to my colleague @MatanYadaev arguments and clarify the trade-off of maintaining Each and every authenticated request is followed by both READ and WRITE operations on the A common scenario of a dashboard page load which simultaniosly fires multiple requests to load different dashboard data, is enough to hit concurrency level that leads to deadlock occurences on the Ofcourse some DB parameter adjustments can be made to mitigate this issue. However, I think reducing the stress on this table by simply making tracking of will appreciate your opinion here before we start working on a suggested PR. |
Please resubmit this with a filled out issue template. It's there for a reason. |
You can override the default model like // in your AppServiceProvider
Sanctum::usePersonalAccessTokenModel(PersonalAccessToken::class); <?php
namespace App\Models;
use Laravel\Sanctum\PersonalAccessToken as SanctumPersonalAccessToken;
class PersonalAccessToken extends SanctumPersonalAccessToken
{
public static function booted()
{
// Prevent updating the last_used_at column on every request
static::updating(function (self $accessToken) {
$dirty = $accessToken->getDirty();
if (count($dirty) === 1 && isset($dirty['last_used_at'])) {
return false;
}
return true;
});
}
} |
Due to a high concurrency on my company's API, Sanctum leads to deadlocks.
This line of code, which updating
last_login_at
is responsible for these deadlocks.sanctum/src/Guard.php
Line 73 in f30df69
My company doesn't need this
last_login_at
column, and I can see that Sanctum doesn't use it anywhere.It seems like an optional column. I guess it exists just for those who'd like to display it to the users or to make some logic above it.
I think Sanctum should provide the ability to choose whether this column is "working" or not. It should be configurable in my opinion.
What do you think guys?
As a workaround, I've used an observer with a
return false
to cancel this update query.The text was updated successfully, but these errors were encountered: