Merrick Schincariol

author
+ Follow
since Aug 15, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Merrick Schincariol

Just wanted to mention a couple of things: first is that the EJB 3.0 spec still includes all of the material in the EJB 2.1 and earlier specifications. The only deprecated (not removed) portion is CMP 1.1 entity beans. If you want to pursue certification, you need to know EJB 2.1 plus the new and changed material introduced in EJB 3.0.

Second, there will be several commercial EJB 3.0 products on the market before the end of the year. As customers move to these new versions, the opportunity exists to start incorporating EJB 3.0 features into legacy applications. It's important to remember that most existing customers will approach this in a careful, incremental fashion. Adopt the new simple style of session bean, for example, but leave CMP in place. So I expect there will be long transition period for existing customers that are still actively developing their applications. It will start this year and continue on for many to come.

Hopefully new application development will focus on EJB 3.0 from the beginning.

Cheers,

Merrick
You can't change metadata on the fly, but when mapped using XML, you can map the same class multiple times to accomodate the case where you want to move data from one database to another, for example.

We provide examples of this in the book. Each set of mappings is associated with a name (the persistence unit), so you can reuse the same class across entity managers associated with different persistence units if the class is shared between them.

Cheers,

Merrick
I believe Mike is referring to the size of the API, not the size of the implementation. The EntityManager and Query interfaces are relatively concise, yet still allow for a significant amount of power and flexibility.

Cheers,

Merrick
Just thought I would jump in on this, since I work on OC4J and can give you some insight from an application server engineer.

Bean instance pooling (or object pooling, but that's a pretty generic term) is still a required part of a modern EJB implementation. In order to satisfy the thread-safety requirements of a stateless session bean, each call needs to have its own isolated bean instance for the duration of the call. Although beans are not supposed to hold state between calls, state on the bean is considered safe for the life of the method call. If a bean has no state, you could optimize this away, but generally speaking the only safe way to implement stateless session beans in a high performance way is to use some kind of pooling.

You could create new instances on the fly, but the bean lifecycle methods can add a lot of overhead to the bean creation process. For example, if you have a significant amount of code that executes during ejbCreate or setSessionContext, that code gets executed every single time a bean instance is created. Pooling expensive bean instances is a win here as well.

Cheers,

Merrick
Hi Georg,

It looks like you don't have a JPA implementation on the class path. JPA can be used just fine in a regular Java client program. Ensure that you have a persistence.xml file in the META-INF directory of your application JAR configured for use outside the container (there are some slight differences). You can either explicitly list the persistence provider or if there is only a single provider on the classpath it should be found automatically.

Cheers,

Merrick
EJB 3.0 is the full specification that includes session beans, BMP entity beans, CMP entity beans, message driven beans and the new Java Persistence API. Because JPA wasn't split into a second document until midway through the specification lifecycle, most people still use the term "EJB 3" to refer to both the simplification changes (POJO session beans, dependency injection) and the new persistence API.

JPA refers exclusively to the new persistence portion of the EJB 3 specification.

Cheers,

Merrick
Hi Ram,

To keep the book down to a manageable size, we chose not to discuss web services. Fortunately, Oracle offers a number of online resources that discuss these issues. On the EJB 3 and JPA sites on OTN you can download howtos that show how to expose EJB 3 session beans as web services quickly and easily.

The Oracle Web Services stack included with OC4J also includes a product called DBWS that was designed to expose PL/SQL packages as web services. It produces a standard EAR file that can be deployed to OC4J and creates a web service operation that corresponds to each of the PL/SQL package operations. Check out the web services documentation in a recent OC4J release for information on DBWS.

Cheers,

Merrick
Good question. The intention of the spec at least (reading between the lines in section 5.6), is that the entity manager is safe to use when injected into a stateless session bean. This is because there is no persistence context associated with a transaction-scoped entity manager. Instead, the persistence context is acquired dynamically, either from the transaction or created temporarily when required outside of a transaction.

In OC4J, the entity manager you inject is really a lightweight and thread-safe proxy that does the right thing when a method on the entity manager is invoked.

The relationship between persistence units, persistence contexts and the things that actually get injected into your application can be complex. We devoted an entire chapter in our book on this topic for just this reason.

Cheers,

Merrick
Hi Adam,

In many cases no vendor-specific file is required at all. I suggest taking a browse through the introductory chapter hosted on OTN or looking at the sample code. The mapping between objects and tables can be done using annotations, a standardized XML file or a mixture of the two.

Cheers,

Merrick
Yes, method interceptors are there, but I wouldn't necessarily claim that it's an AOP solution. Introductions and field interception are missing compared to other AOP solutions.

That said, interceptors are generally what most people are looking for when they think of AOP. In OC4J, all of the system services, from transaction management to security are all implemented as method interceptors. Used correctly, they can lead to a decoupled and easily extended architecture.

Cheers,

Merrick
Hi Ram,

The examples for the book available on the Apress web site expand the example in the book to show a simple working client. The persistence.xml file goes in the META-INF directory. This is discussed briefly at the end of the chapter and then in detail later in the book.

TopLink Essentials is the reference implementation of the JPA. Oracle contributed it to the GlassFish project to ensure that a high quality reference implementation would be available. It is a derivative of the commercial TopLink product.

Cheers,

Merrick
There is no silver bullet, but we included a chapter on migration that discusses a number of different techniques you can use to convert legacy EJB entity beans into JPA-style entities.

Cheers,

Merrick
Hi Pradip,

Java EE clients support dependency injection into static fields. So a remote EJB client can inject the bean reference without having to use JNDI.

Cheers,

Merrick
The query language in the Java Persistence API is far more sophisticated than the original EJB QL introduced in EJB 2.0. Subselects, grouping, outer joins, functions, etc. have all be added or expanded in the new release. Plus, the object-relational notation can express very complicated queries in a compact, yet expressive form.

JPQL can't support all database features, but my experience so far is that it can handle the majority of business queries without issue. For the real nightmare queries, JPA also allows fallback to SQL with mapping to entities.

Cheers,

Merrick
Hi Satou,

Rod Johnson himself contributed the forward to our book, and I think it's safe to say that they see JPA as a big step forward in enterprise Java persistence. The next release of Spring is expected to include direct support for the Java Persistence API.

The area where Spring and EJB 3 tend to collide is in terms of the component model. Both solutions offer a simple, POJO-based component model and dependency injection. In many respects the EJB 3 model is a subset of the Spring component model, but on the other hand your application may not require the added features offered by Spring.

In any case, I view the two as being compatible, and we even included an example of using Spring to test EJB 3 session beans in the book. I think that EJB 3 offers a compelling solution, and don't expect it to be overshadowed by Spring.

Cheers,

Merrick