tmpfsは、ramdiskのようなものなのですが、サイズを動的に自動調整してくれます。そして、swapのように、memoryとdisk間のやりとりも自動でやってくれます。dWを参照。
設定は簡単です。まず、kernel optionで、File Systemにて、Vertual Memory Support(shm fs)がONになっているか確認します。そしたら、
# mount tmpfs /tmp -t tmpfs
すればOK。ブロックデバイスではないので初期化も不要です。umountは、
# umount -t tmpfs /tmp
です。fstabに書くには、
/dev/shm /tmp tmpfs defaults 0 0
とすればよいでしょう。
ディスクを提供するサーバーは、kernelでやるかuser modeでやるかの2択です。後者の場合は、nfs-user-serverとnfs-commonとをapt-get install。hosts.allowなどでportmapを有効にし、NFSで提供するディスクを/etc/exportsで教えてあげればOK。
クライアント側は、nfs-commonをapt-get installし、mountすればOK。
MavenでEARを作るのは面倒だと以前書きましたが、これはMavenのせいではないように思えてきました。もともとEAR（J2EE）の開発は大変なのです。
J2EEの設計思想は、JAR,WAR,EJBの開発者は別々で、それらを集めるアセンブラ、配備するデプロイアも別々で、しかも同時期にそれらが開発される・行われるとは限らず（コンポーネントを買ってくる）、扱うデータベースなど他のシステムも多種多様というのを想定しています。それに最適化するのがJ2EEなのです。それらを一人でやろうとすれば大変なのは当然です。逆に言うと、効率的なJ2EE開発をするには、そのような開発組織を組む必要があります。
つまり、EJBは、O/R mapping技術というより、むしろ、開発プロセス・開発体制に近いのです。だから、技術部分だけをとりあえげて、EJBと他のO/R mapping toolsとを比較しても、あまり有益ではないでしょう。もちろん、J2EEが想定しているそのようなプロセスが、現実にそくしている・そぐわない、といった議論は別途必要です。
J2EEといえども、所詮「フレームワーク」に過ぎません。道具なので、利用目的にそって選ばないといけません。J2EEの大きなプロセスをとれないのなら、別の技術の選択を考えたほうがよいかもしれません。
それから、「フレームワーク」とは、あまりできない人（組織）がそれなりにできるようになるためのものだと最近私はとらえています（善悪の判断をしているわけではないですよ）。Strutsしかり、デザパタしかり、EJBしかり、XPしかり、ひょっとしたら、Object-Orientedしかりかもしれません。細かなフレームワークにとらわれずに、もうちょっと自由な発想でよいのではないでしょうか。