JPAを使ったデータアクセスでポイントとなる永続コンテキストについて - 達人プログラマーを目指して
先週書いたエントリJava EE6標準の範囲でフルスタックのWebアプリケーションが簡単に作成できることを確かめてみました。 - 達人プログラマーを目指してで、Java EE6の標準仕様を使うだけで、かなりシンプルにデータのCRUD処理を行うアプリケーションが作成できることを紹介しました。ただし、前回は全体のアプリケーションを紹介しただけなので、細かい仕掛けについては解説しきれませんでした。今回は、前回に引き続き特にJPAを使ったデータベースアクセスの部分がどうなっているのかをもう少し掘り下げて解説してみたいと思います。 なお、この場で宣伝ですが、8月10日（水）にGlassfishユーザーグループの勉強会にてお話をさせていただくことになりました。 GlassFish Japan Users Group 勉強会 2011 Summer : ATND 私はJava EE6を使った開発について
J2EEレガシーアプリケーションのJavaEEアプリケーションへのマイグレーション(1) - 水まんじゅう2
何回かに分けてJ2EEレガシーアプリケーションのJavaEEアプリケーションへのマイグレーションについて実際のコードを見ながら解説したいと思います。 変更前のサンプルソースはこちら https://github.com/megascus/oi-webapp-sample/tree/initial こちらのソースは、Tomcat上で動く、ビューがServlet2.5+JSP、O/RマッパーとしてHibernateを直接使用するという、大体2005年ぐらいに作られたシステムのイメージになっています。 また、いくつかの点にてきちんと設計されているとは言えず、MVCに沿って作られたことになっていますが、きちんとViewとModelが分離できていません。 それ以外にも問題をいくつか抱えています。 これをGlassFish4.0上でのJavaEE7仕様で作り直したいと思います。 古いシステムを新しい仕
はまる!！JPA #glassfish_jp #javaee
弊社ではシークレットの管理を自社のSecrets Managerによって管理しており、ほとんどの社内プロダクトはこれと連携しています。Secrets Managerと自社Kubernetes基盤との連携は最適とはいえず、Kubernetes上のアプリケーションからシークレットを利用する際の、利便性の悪さや、シークレット取得のための認証情報の管理にリスクがあるなどの問題がありました。 従来の解決策として、External Secrets OperatorやSecrets Store CSI Driverなどがありますが、エコシステムに組み込むにあたってSecrets Store CSI Driverに強みがあり採用しました。そしてKubernetes環境により適した安全なシークレット管理を実現するため、自社のセキュリティ基盤と連携しプラットフォームレベルでシークレットの提供がサポートができる
JPA 2.0の新機能 悲観的ロックを試す - しんさんの出張所 はてなブログ編
JPA1.0では楽観的ロックだけ仕様が定義されていた。実際は各プロバイダが独自にヒント等で悲観的ロックを用意していたのだが、それもやっと定義されたために安心して使うことが可能だ。 楽観的ロックはバージョン番号を用意し、トランザクションの開始直前に取得した番号を元に更新にしくというもの。もしそれが存在しない場合、すでに更新されたものとみなし、トランザクションを最初からリトライさせる。 たまに楽観的ロックのようにバージョン番号を利用した値を画面表示時にあらかじめ持っておくといった、アプリケーションでのロックをかけてるところも多いけど、それは楽観的ロックではなく、そういう仕様のアプリケーション。あくまでもトランザクションをどう整合性とるかというだけが楽観的ロックだ。 そもそも更新時にはどのみち行ロック等がかかるわけで。更新方法によってロックがかかる順番が変わることも多いため、デッドロックの可能性
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://blogs.oracle.com/carolmcdonald/entry/jpa_caching
