Hobione's Weblog

Living & Breathing in Web 2.0 Era

RichFaces, JPA trial and error

Issue # 1. I wanted to use RichFaces Modal Panel to pop up a login screen and I got an error. Instead of going to login.xhtml, it was giving me file download error like this.

Solution: In my web.xml file I added <welcome-file>index.xhtml</welcome-file>. I had to change index.xhtml to index.html to make it work. I guess application initialization it does not know what is xhtml. Once application get initialized, then it recognizes the xhtml extension.

Issue with Persistence Model: Exception occured in J2EEC Phase
com.sun.enterprise.deployment.backend.IASDeploymentException: Deployment Error — The persistence-context-ref-name [persistence/LogicalName] in module [C:\buildLocal\WebDMS\build\web] resolves to a persistence unit called [WebDMSModelPU] which is of type RESOURCE_LOCAL. Only persistence units with transaction type JTA can be used as a container managed entity manager. Please verify your application.

Jason: Drop the type=”” (?) decl from your persistence declaration, or change it to JTA
OR stop using injection to get your EntityManager

Jason: <persistence-unit name=”WebDMSModelPU” transaction-type=”JTA”> or <persistence-unit name=”WebDMSModelPU”>
JTA is the default. if you have “RESOURCE_LOCAL”, that tells JPA that you will handle txn mgmt yourself. a container-managed EM can’t work in that… mode

So here is my workable persistence.xml looks like:

<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="WebDMSModelPU" transaction-type="JTA">

More details on this issue: David’s blog, JSF ForumIssue 3: This was very weired. My accordion image was not showing up when I did a hot deployment to the development server from my local machine. But it worked on the local machine.
Solution: It worked after spent couple hours. I had to re start our development application server
SJSAS 9.1 UR 1) to see the change.withimg.jpgIssue # 4: Scrollable Data Table wont render data.

<rich:scrollableDataTable  id="projectTable" var="project" value="#{controller.projectList}" first="0" rows="20">

Solution: I was returning a DataModel instead of List. I assume, scrollable data table does not work with DataModel.2 cents from Jason: I’ve never used DataModel, always using a List. Internally, dataTable will convert a List to a ListDataModel, for what that’s worth. Apparently, I lose some things by not using a DataModel, but I’m not sure what that is yet. :)HH: I must say that RichFaces is such a sweet JSF component libraries to work with. Awesome. Full credit goes to Jason Lee, who introduced me with it. I have tried Sun’s Woodstock and few other libraries, but RichFaces has the best documentations, it is very easy to use and more frequently version updates.

March 20, 2008 Posted by | Java Persistence API, Java Server Faces, Jboss RichFaces (Ajax4JSF) | Leave a comment

JPA with Hibernate, Toplink etc…

Conversation with Jason Lee to generate Persistence API Entity class

HobiOne: How do create entity class? Do you write all these or use some script

Jason: Do you already have the schema built in a database?

HobiOne: yes

Jason: Ok…iirc, Eclipse has a plug-in that will do that for you, and there might be some Hibernate utils for that

HobiOne: Netbeans does it too but I was not sure what the standard, use IDE or hand code is

Jason: I don’t think there is a standard. you just use what works for you

HobiOne: So do you use Eclipse to generate?

Jason: I usually hand code, but my schema is either small enough or not defined yet )

HobiOne: Can you create schema and entity class at the same time?

Jason: sure

HobiOne: nice

HobiOne: One more question

Jason: Ok…ask all you want )

HobiOne: By using JPA, I have to use Hibernate or Toplink but if I use Hibernate or Toplink, I don’t have to use JPA, is it correct?

Jason: Right

HobiOne: So, JPA is like a driver, it gives the flexibility to switch Persistence API like Hibernate or Toplink

Jason: it’s an abstraction layer, yes

HobiOne: Does it put any overhead?

Jason: Not that I’ve noticed. I don’t think it does, as it only defines a set of interfaces

HobiOne: Uh ha, I see

Jason: Hibernate, say, then creates a class like HibernateEntityManagerImpl that implements that interface, and you use that, though your reference to it is of type EntityManager.

Some Key terms about Persistence Framework from POJOs in Action:

Persistence framework a.k.a Object/Relational Mapping Framework

Object Model = Domain Model

Encapsulating the business logic: Good candidate to encapsulate the business logic are how to handle transactions, security and remoting.

POJO facade: A better approach uses a POJO facade in conjunction with an AOP-based mechanism such as the Spring framework that manages transactions, persistence framework connections and security. The POJO facade approach simplifies development by enabling all of the business logic to be developed and tested outside the application server.

Handling concurency in database transactions

  1. Isolated database transactions
  2. Optimistic locking
  3. Pessimistic locking

Role in the domain Model

  1. Entities: Object with distinct identity. PendingOrder, Order, Restaurant
  2. Value objects: Objects with no distinct identity. Address, User
  3. Factories: Define methods for creating entities. A Java application creates objects by using the new operator. Sometimes, using the new operator directly is sufficient, but if you need to instantiate a complex graph of objects or you need to vary the types of the objects that are created, then you might need factory. A factory defines methods for creating entities. It encapsulates the mechanism that instantiates a graph of objects and connects them together, which simplifies the client code.
  4. Repositories: Repositories manage collections of entities and define methods for finding and deleting entities which encapsulate the persistence framework
  5. Services: Implemet responsibilities that can’t be assigned to a single class and encapsulate the domain model

Jump Start to JSF JPA: Use Netbean’s tutorial

March 12, 2008 Posted by | Java Persistence API | Leave a comment

Store Procedures + JPA – Performance Issue

If we call store procedures from JPA, are we going to loose any performances? Our concern is, may be we should think either JPA or store procedures. If we decide to use both, we might not take full advantages either or, please correct me if I am wrong.

Seems like you’re worried about performance without having anything to measure. That’s something to avoid.

Bottom line, I have seen companies:

– Use strictly stored procedures
– Use no stored procedures
– Use a mix

I have seen successes and failures in both cases.

Performance issues are related more to your schema, locking strategy and access mechanisms than to using stored procedures versus an ORM.

Using JPA will probably get you something to demonstrate faster and sooner. It also allows you to work with different database vendors – which may not be an issue. As you develop, make sure you’re hitting the high-value stuff from the customer or user’s perspective early. When/if you find performance issues, fix them. That’s the best thing you can do.

Don’t start de-normalizing your schema until you absolutely must. Start with as close to 3rd normal form as you can manage (higher-order normalization is not often worth it). Use views before you de-normalize. Views will slow down inserts but increase reads, which is probably what you’re more concerned about. IF your system does more writing than reading in some places, don’t use views there.

Until you know what your users are going to be doing, you cannot optimize your stuff. So you MUST keep it clean and un-optimized so that when you’re ready to start making performance enhancements based on ACTUAL DATA, you’re starting with less of a mess. It is VERY hard to optimize code in one direction if it has been optimized in another.

Finally, you’re a service. Independent of technology, a remote service needs to have chunky (opposite of fine-grained) API calls. Your individual methods (regardless of state) should do a lot in each request. WHY? The overhead of a remote class versus a local call is 10,000X or much worse.

Web services are no exception. You’re going to need to have chunky messages. The communication protocol is going to be SOAP of HTTP, right? HTTP is not fast and SOAP is bloated, so your messages are going to require multiple IP packets. Your messages will need to do a lot.

Oracle Toplinks vs. Hibernate, is there any advantage one over other or this is just a personal choice?

I have no idea. Toplink has been around many more years. I believe Hibernate is a better design. I don’t know that you’ll notice much of a difference.

HOWEVER, if you use JPA, it won’t matter as much. JPA gives you one level of indirection on top of your ORM.

In your wiki site, you have tutorials for pure JPA and EJB 3 and JPA, would you explain differences between two.

JPA can be used in a JSE environment. When you do so, it’s like using JDBC on steroids (I would no longer recommend using JDBC if you can use JPA).

However, JPA by itself does not start/stop transactions. You must manage sessions, etc. That’s not a bad thing, it’s just a thing.

When you use EJB3, you get JPA automatically. There is a key difference (ignoring extended contexts)

– Every individual method on a session bean starts a transaction
– When you leave that method, the transaction is committed unless rollback was enabled during the processing
– You get a new session (first level cache) at the beginning of each method
– That session is dumped when you leave the method.

So every call to a session beans commits changes and creates and then destroys a session.

You also have an extended context. The extended context maintains cached objects (the session/1st level cache) between method invocations. It does so until a method annotated with (I believe) @Remove is called.


March 5, 2008 Posted by | Java Persistence API | Leave a comment

StoreProcedures or Persistence APIs (Hibernate, Toplinks, JDO)?

I have chatted with Brett Schuchert and here his suggestions:

1. Choice between store procedures and persistence API. Performance wise, is it one better than other?

If you’re looking for raw performance, stored procedures are generally faster but that all depends on what you’re doing. Here are some differences:

1. Stored procedures can be faster for some operations, however for many lookups, queries are more than adequate

2. Hard to version in an RCS, not impossible

3. Harder to unit test, but not impossible

4. Often ends up implementing business rules in multiple places

5. Ties you to a vendor – might be OK – because each database vendor has their own way of doing it

So I’m not a big fan. However, sometimes they are what you need. It’s not an either-or choice… See below.


2. Is it possible to create an ORM to a store procedure?

It is possible to call a stored procedure, but creation? I do not know. I don’t think so.

3. Can an application use both, Store Procedures and Persistence Framework?

Yes. You can call stored procedures from JPA. You can look them up by name and invoke them.

4. Which is easier to maintain?

I believe code and the mappings in an ORM.

5. Which is better suited for a large-scale application especially on the web?

Both will work. I have a bias towards using my middle-tier language, I’ve seen places that use strictly stored procedures for everything – they also tend to be more fragile.

6. How well a web services work with JPA?

As for JPA and web services. I see them as orthogonal… that is, either can be used with or without the other.
Many web services will end up using a database. Using JPA for that is a natural thing to do. If your web service is simply a repackaged EJB 3-based session bean, then you’ll have access to JPA. If not, then you’ll want to make sure to define the interaction of the web service such that each individual method can start and then either commit or rollback.

Typically, web services are stateless, so trying to maintain extended conversations, while possible, is a bit against the grain.

Thanks Brett, appreciated


March 3, 2008 Posted by | Java Persistence API | 2 Comments