Shailesh Kini

Ranch Hand
+ Follow
since Oct 17, 2001
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 Shailesh Kini

Hello John,

I suspect it could be an issue with the jndi name "java:comp/env/FibonacciBean". Please try including the ejb context in your lookup "java:comp/env/ejb/FibonacciBean"

Hope this helps.
Hey Jay,

It is not clear if the table protein has 4 mil rows or the related tables have 4 million rows?

You should add filtering to your query. If you are interesting in a subset of the records use JPQL to build your entities.

You could also try to increase the max heap space on your jvm.
Hello Benson,

I still do not understand your confusion.

These 3 documents indicate 3 different ways to access the EJB container.

1. SSL
2. HTTPS
3. RMI

You have to just pick the one that's most appropriate in your situation. RMI does not work if your client tier is outside the DMZ.
Mike,

First of all I would like to thank you for the wonderful Pro EJB 3: Java Persistence API book. It is a must have for everyone interested in working with or just wanting to know about JPA.

We are using Toplink essentials and just went live with it. No bugs to report so far.

In my opinion the most important feature missing from JPA is the built-in support for clustering. However, there are different approaches available to add it manually.
[ January 15, 2008: Message edited by: Shailesh Kini ]
Hello Benson,

Happy New Year to you too!

If you have all your ejb's deployed on the LDAP server that is ssl enabled then in my opinion you should be create an initial context with some SSL specific properties. Please re-read the document SSL LDAP especially "Using the SSL Socket Property" section to understand how to do a lookup on a SSL enabled LDAP server.
Avihai,

You stateless session bean should throw a RemoteException which you could catch on the SWT side just to display a user friendly exception.

If you want to handle the error on the server side just create a new method that actually has all the business logic and encapsulate it with your current business method. You should be able to catch Exceptions on your EJB later and send some user-friendly message to the client.
Hello Benson,

Here's a link to the ejb lookup example

EJB Lookup

Generally LDAP services listen on Port 389 for non-SSL and Port 636 for ssl. But these ports numbers are configurable.
Hello Peter,

Can you please add the Patient entity code to your post?
Hello Bala,

J2EE 1.4 onwards JTA was implicitly supported by all compliant app servers. If you have only one resource either nonXA or XA participating in a transaction then it automatically starts a one phase commit(local transaction). It more than one nonXA resource participates in a local transaction... then the transaction is rolled back. If more than one XA resources participate in transaction then the transaction becomes a global transaction(2 phase commit).

Ideally for a 2 phase commit(global transaction) all resources must be XA or else the transaction is rolled back. However most of the servers support something called as "last agent optimization" which allows one and only one nonXA resource to participate in a global transaction (2 phase commit). So if you have set this flag to true on your appserver's transaction service then you should not get any rollbacks due to XA and nonXA resource participating in a global transaction
Hello Peter,

Generally most of the OnetoMany relationship should be bidirectional. In your case @OneToMany relationship exists between the owning side Medic and the Patient. Your join table is MEDIC_PATIENT which should be specified on the target (Patient) entity with a @ManytoOne(mappedBy="patients") annotation. You should also use the @JoinTable annotation on the Patient entity.

JPA won't know of your join table unless you specify it somewhere.
Mark,

You are correct, my bad! Thanks for correcting me. We do not need to call flush before commit. Calling commit should flush automatically.
[ December 29, 2007: Message edited by: Shailesh Kini ]
Hello Abhijith,

How are you deploying this application? Where is the persistence.xml located in the archive?
Hello Arun,

Do you use an ear file for your deployment?

[Excerpt from wikipedia]
Different artifacts can be embedded within an EAR file, artifacts which are deployed by the application server:

* A Web module has a .war extension. It is a deployable unit that consists of one or more web components, other resources, and a web application deployment descriptor. The web module is contained in a hierarchy of directories and files in a standard web application format.
* Arbitrary Java classes may be deployed in .jar files.
* An Enterprise Java Bean module has a .jar extension, and contains in its own META-INF directory descriptors describing the persistent classes deployed. When deployed, entity beans are visible to other components and (if remotely exported), remote clients. Message Beans and Session Beans are available for remote access.
* A Resource Adapter module has a .rar extension

Vendors may support extra artifacts, with their own extensions.
Hi Mark,

You are maintaining the State "User" in a stateless session bean. You cannot guarantee that you would get the same instance of the stateless session bean everytime. If you plan to maintain state please switch to Stateful session bean. That should fix your issue. But you have to be very careful to remove the Stateful session bean once you are done.

Alternately you could just return the User from one of the methods in your stateless session bean.

Hope this helps.
Sridhar,

I still feel you should call the hibernateSession.flush() before you call tx.commit(). Here's my thought... calling flush() synchronizes the entity with the database. However you are calling commit before the synchronization happens and there is nothing to commit as the entity state has not yet been flushed.

Just change the order of these two statements
tx.commit();
hibSession.flush();

to
hibSession.flush();
tx.commit();