Erik Bengtson

simply do not use JPA. It has enormous footprint. Also, you have to consider for each entity class:

-classes are redefined in memory
-metadata has be loaded and hold in memory
-adapter classes for DB
-JPA implementation objects
-db metadata
-garbage collection
-unnecessary fetched objects
-the list goes on...

Just stick to JDBC

Erik Bengtson
http://jpox.org (JPOX is a JDO and JPA implementation)

do you have weblogic.jar or wl-client.jar in your client classpath?

A sequence in JPA maps to a database sequence. You should check your DB first.

select <seqname>.NEXTVAL FROM DUAL

if it gets incremented by 1, then check your code, later report a bug to the jpa vendor

JPA does not support collections of dates. it only support collection of entities...

You need to wrap your date within an Entity (argh)...

FYI, JDO supports collections of any type.

Marco, you don't need any instance variable...

JPOX is offering Sony PSPs to students that contribute extensions to the project.

The contributions we look for should be aligned to the project, but could be for example:

- support to a new relational database
- support to custom database types
- support to LDAP or XML database
- tools, such as JPOX Eclipse plugin and integration with Eclipse Dali
- etc...

5 students will be selected to participate, contribute and win a Sony PSP.

JPOX is a JDO 1, JDO 2 and JPA implementation.

See more at:
http://www.jpox.org/servlet/forum/viewthread?thread=4426
http://www.jpox.org/summercode.jsp

A RuntimeException is thrown

You can let the container rollback the transaction in case of exceptions, so your answer can be just "None". :-)

In JPA you can either use annotations or orm.xml metadata file to define database related information.

Another JPA implementation to try is JPOX. The implementation that I'm developing

http://jpox.org

Not mandatory, but helps. Experience also helps too.

42 questions on subjects:
- Portal
- WLI
- SAML
- Cluster
- J2CA
- WLI controls
- UML
- Service Policy and Registry

ORM faster than stored procedures is urban legend.

ORM engines add overhead on the top of JDBC and queries are not always compiled to the most performing SQL (another urban legend).

ORM engines come with caching systems where you could eventually achieve good performance comparing to JDBC or even stored procedures. This depends on the profile of your data and application. Mostly, you benefit using ORM when your data is immutable or does not change very often.

If someone says that his ORM engine outperform stored procedures, you can challenge this person.

The more you push down to database processing the fastest will be the data processing.

On the other hand the more processing is pushed down to database the less you scale (not if you have a clustered db).

Popping data from DB to Java and doing processing has its costs (mostly i/o).

All of above is purely tech, and the mind change is moving business from stored procedures to a business layer (java, .net), which, in theory, allows to quickly adapt for business changes and expose data as services to several systems.

The architectural choice from putting business data processing in java will bring several benefits that will shadow the performance loss. Systems are becoming very complex and SOA is here to stay. The goal now is no longer data centric, but distributed and available to different business units. The database server is no longer capable to head the business of large organizations.

In any case, if performance loss is not a consideration them you should consider C++. Under the scenes java uses C++ to improve performance anyway.

FYI, I'm a developer of JPOX, a JDO implementation.

Go for ORM, but be sure to understand its limitations.
[ October 20, 2006: Message edited by: Erik Bengtson ]

There is one where you can get a free online copy. The author is Robin Ross

In WLS 9.x use WLST configToScript command.

In WLS 8.x:

- create a domain template
- run config.sh with a silent script

loadTemplate '...'
....
...

see the docs for examples

- create ant scripts or use weblogic.Admin to configure/create MBEAN

Originally posted by Mike Keith:
Hi Eric,
Actually, as a general rule I don't "fight against" JDO. There were a lot of good things in that spec and I don't have anything against either the spec or the great folks that contributed to it (you amongst them!). I do pipe up, though, when people say outrageous things like "JDO 2 is a far better specification than any other standard" since it is not only very biased but I believe quite misleading to readers.

As to the future of JDO, most people have expressed the same opinion, but I won't say what it is. Anyone that cares or that is interested should do their own homework and come to their own conclusions, not get them from people closely affiliated with either the JDO spec (you guys) or the JPA spec (me)

Mike, neither I am fighting against JPA, however I expressed my own opinion, and want to make sure people is aware of each API capabilities.

The comparison I'm compiling is supposed to be informative and non biased. The objective is to show their differences for JPOX users before choosing which API to use. The homework here is a JPOX job, since it's a product offer.

I also think that such comparision could be useful for the JPA group to evaluate the features it currently lacks in relation to JDO.