NSTanechanのブックマーク - はてなブックマーク

ID生成大全 - Qiita
セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。そこで世間で使われているIDの生成方法について調べてみました。選択基準 ID生成における要求として、以下の観点が上げられるかと思います。生成の速度大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。順序性採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。それぞれについて各生成手段を評価します。 ID生成の手段データベースの採番テーブル採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い
NSTanechan 2017/12/02
リンク
【随時更新】JDK9の非互換ポイント - Qiita
JDK9でいくつかImcompatibleな問題に直面したので、ここにGitHubのIssueから、各プロダクトで挙がっているJDK9の不具合ポイントをまとめていきます。 java.specification.versionの体系変更 JDK9からは、JEP 223にともない、バージョン番号の表記が変わりました。そして、システムプロパティjava.specification.versionの返す値も従来の「1.8」みたいな値から「9-ea」が返ってくるようになっています。このため、HibernateValidatorでは、以下の箇所でArrayIndexOutOfRangeExceptionが出てしまっていました。 String[] specificationVersion = System.getProperty( "java.specification.version" ).spli
NSTanechan 2016/04/07
リンク
メールのトランザクション設計 - Qiita
3日目で息切れしてきたので、今日は軽めな内容です。データベース更新とメール送信の一貫性商品購入の完了ページなど、よくデータベースを更新して、メールを送信してデータベースをコミットするという仕様があります。データベース登録出来てないのに、完了メールを送るわけにはいかないので、これらを1トランザクションにできなきゃいけません。が、SMTPプロトコルにコミット/ロールバックの概念はありません。さて、どう設計しましょうか、というお話です。方式 A.DBトランザクション後にメールを送る同一トランザクションはあきらめ、データベースを先にコミットし、その後でメールを送る、という設計です。メール送信でエラーになったら、データベースには書き込めているので、メールだけ再送するように仕組みを作ったりします。以下のようなイメージです。 public class OrderController {
NSTanechan 2015/12/04
リンク
1