<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>concurrency on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/ja/tags/concurrency/</link><description>Recent content in concurrency on Ikoma's Blog</description><generator>Hugo</generator><language>ja-jp</language><lastBuildDate>Sun, 30 Aug 2026 13:34:18 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/ja/tags/concurrency/index.xml" rel="self" type="application/rss+xml"/><item><title>リフレッシュトークンをローテーションすると、並行リクエストでログアウトされることがある</title><link>https://blog.yusukeikoma.com/ja/posts/refresh-token-rotation-concurrent-requests/</link><pubDate>Sun, 30 Aug 2026 13:34:18 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/refresh-token-rotation-concurrent-requests/</guid><description>リフレッシュトークンのローテーションは、使用済みトークンの再利用を盗難の警報として扱います。期限切れのアクセストークンで3つのリクエストを同時に送り、401ごとに更新するクライアントは、同じリフレッシュトークンを3回提示して、自分で警報を鳴らします。この記事では、素朴なクライアントをあえて壊し、single-flight と stale check で直します。そのうえで、サーバー側の猶予期間、リクエストの待機、先回り更新、送信者制約付きトークンを比べます。</description></item><item><title>開始の許可を未終了のあいだ一つにする</title><link>https://blog.yusukeikoma.com/ja/posts/one-open-admission/</link><pubDate>Wed, 12 Aug 2026 10:27:31 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/one-open-admission/</guid><description>分散タスクの同時実行制御として、作業面ごとの開始許可・投入時の宛先固定・マシン停止時の冪等な再送を設計する方法を説明します。</description></item><item><title>Go デーモンと Python API の堅牢化</title><link>https://blog.yusukeikoma.com/ja/posts/go-daemon-and-python-api-hardening/</link><pubDate>Sat, 01 Aug 2026 14:11:31 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/go-daemon-and-python-api-hardening/</guid><description>複数言語が同居するコードベースで得た 5 つの手法をまとめます。既存の Go コードへの golangci-lint の段階導入、CI でのレースディテクタの常時実行、サブプロセスの寿命の制御、bootout の競合を避けた launchd サービスの再登録、そして外部キーを踏まえた PostgreSQL の行ロック強度の選び方です。</description></item></channel></rss>