先週書いたエントリJava EE6標準の範囲でフルスタックのWebアプリケーションが簡単に作成できることを確かめてみました。 - 達人プログラマーを目指してで、Java EE6の標準仕様を使うだけで、かなりシンプルにデータのCRUD処理を行うアプリケーションが作成できることを紹介しました。ただし、前回は全体のアプリケーションを紹介しただけなので、細かい仕掛けについては解説しきれませんでした。今回は、前回に引き続き特にJPAを使ったデータベースアクセスの部分がどうなっているのかをもう少し掘り下げて解説してみたいと思います。 なお、この場で宣伝ですが、8月10日（水）にGlassfishユーザーグループの勉強会にてお話をさせていただくことになりました。 GlassFish Japan Users Group 勉強会 2011 Summer : ATND 私はJava EE6を使った開発について
テーブル create table movie ( id identity, name varchar(50), primary key (id) ); create table actor ( id identity, name varchar(50), primary key (id) ); create table movie_actor ( movie_id bigint, actor_id bigint, primary key (movie_id, actor_id) ); Movie.class package sample; import java.io.Serializable; import java.util.ArrayList; import java.util.List; import javax.persistence.CascadeType; import j
何回かに分けて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仕様で作り直したいと思います。 古いシステムを新しい仕
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
これはJava EE Advent Calendar 2013の21日目 昨日は[twitter:@Hachiro808]さんのThymeleafを業務で使いたいでした。 皆様はJPAのL2キャッシュというものをご存知でしょうか。 L2キャッシュとは エンティティをキャッシュし、複数のスレッド間でエンティティを使ってデータをやりとりする場合にいちいちデータベースにアクセスしなくて良くするためのキャッシュです。 普通にエンティティのキャッシュです。ちなみにL1キャッシュというのもありまして、そちらは同じスレッド内で同じエンティティを取得する場合に毎回DBにアクセスしに行かなくて良くするためのキャッシュです。 詳しくはOracleの人が書いた資料があったのでそちらを参照してください。 JPAのキャッシュを使ったアプリケーション高速化手法 超クセモノなL2キャッシュ とまあ、字面だけ見ると非常に
ちなみに金魚本というのは以下の本です。 Beginning Java EE 6~GlassFish 3で始めるエンタープライズJava (Programmer's SELECTION) 作者: Antonio Goncalves,日本オラクル株式会社,株式会社プロシステムエルオーシー出版社/メーカー: 翔泳社発売日: 2012/03/09メディア: 大型本購入: 5人 クリック: 147回この商品を含むブログ (29件) を見る スライドは公開しましたが、勉強会にて口頭で補ったことが多かったので補足します。 JPQLとは JPQLとはJPAで使われるクエリ記述言語です。 Entity および Entity 間のリレーションに対して問い合わせを行う事ができます。 SQLを直接記載しないため、データベースごとのSQL方言等を意識する必要がありません。*1 そのため、可搬性に優れたアプリケーショ
JPOUG Tech Talk Night #2 で話した内容に飲み会で質問された内容を加えています。
{今年|今月|今週|今日}も何%過ぎました ゆく河の流れは絶えずして、しかももとの水にあらず (鴨長明:荘子) FESTINA LENTE ゆっくり急げ (ローマ帝国初代皇帝 アウグストゥス) 立派にできたのであれば、それは十分早くできたことになる (ローマ帝国初代皇帝 アウグストゥス) 海豹日記 へようこそ このサイトは、個人的な覚書を残しておくサイトです 自分は、よくこんなことをします 何かの困りごとや興味の赴くままに、いろいろ調べる 数か月後に、そのことを忘れてしまって、同じことについていろいろ調べる。しかし、そのうち、数か月前の自分が、同じことを同じように調べていたことに気づく それは不毛なので、覚書を残しておこうというわけです (主人公のアリスに掴まれて、チェス盤のはるかかなたまで持ち上げられたことのあるチェスの王さまが、当時のこと思い出し) 王さま「あの瞬間の恐怖といったら、わ
今日は開発メンバからJPAに関して 「XXテーブルに明細データとして保存時に50～100レコードくらい追加する処理があるんですけど、for文で回せばいいんすかね？」 と聞かれました。 そういえば金魚本には一括更新と一括削除はあったけど、一括INSERTってなかったような…と(^^;未だに知識が金魚本ベースな自分。 JSR 317のドキュメントも簡単にみてみましたが、やはりbulk updateとbulk deleteしか見当たらない…。記述があったらごめんなさい…(^^; けれど「bulk」いうキーワードを得て「JPA bulk INSERT」とか「JPA batch INSERT」でググってみました。 が、あまり「これだ！」というのが見つからなかったです。 Portable JPA Batch / Bulk Insert Batch inserts using JPA EntityMan
JPAは基本的なCRUDは標準で使え（データマッパーパターンなので当たり前）、定型的なクエリはNamedQueryとしてあらかじめ静的に設定しておくことができる。 しかし、完全に静的ではなく、起動時に少しいじりたいなどほんの少し動的な性的静的なクエリを作りたいこともあるはずだ。 というわけで、2.1ではNamedQueryをコードで作れるようになった。 定義 EntityManager em = emf.createEntityManager(); String sql = "select address , count(*) as count from customer group by address"; Query q = em.createNativeQuery(sql,"address_count"); em.getEntityManagerFactory().addNamedQ
前エントリで、NativeQuery・JPQL・CriteriaAPIのどれが一番速いのかパフォーマンス比較を行い、NativeQuery悪くないじゃん、と結論づけました。そして、JavaEE AdventCalendar 2013を取りまとめて頂いた@megascusさんや、このネタを書く発端となった@yoshioteradaさんを始めとする多くの方々にコメントを頂きました。ありがとうございました。 その中で、JPQLをNamedQueryで宣言しておくと、起動時にプリコンパイルされるのでパフォーマンスが向上する、との情報を頂いたので、再実験してみました。 今回使用したソースはこちら 前回との差分を簡単に振り返っておくと、まず、JPQL文をfindProductという名前をつけて、EntityクラスにNamedQueryとして宣言しました。 @Entity @Table(name="pr
JPA1.0では楽観的ロックだけ仕様が定義されていた。実際は各プロバイダが独自にヒント等で悲観的ロックを用意していたのだが、それもやっと定義されたために安心して使うことが可能だ。 楽観的ロックはバージョン番号を用意し、トランザクションの開始直前に取得した番号を元に更新にしくというもの。もしそれが存在しない場合、すでに更新されたものとみなし、トランザクションを最初からリトライさせる。 たまに楽観的ロックのようにバージョン番号を利用した値を画面表示時にあらかじめ持っておくといった、アプリケーションでのロックをかけてるところも多いけど、それは楽観的ロックではなく、そういう仕様のアプリケーション。あくまでもトランザクションをどう整合性とるかというだけが楽観的ロックだ。 そもそも更新時にはどのみち行ロック等がかかるわけで。更新方法によってロックがかかる順番が変わることも多いため、デッドロックの可能性
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
