/dev/null productions

Say you’re happily coding along and getting ready to call a PL/SQL package. You fire up your trusty EntityManager and slap a new query together…


em = EmFactory.getEntityManager(authentication);
em.getTransaction().begin();
StoredProcedureCall call = new StoredProcedureCall();
ValueReadQuery query = new ValueReadQuery();


All pretty standard stuff so far. Anyway, you slap a call together and execute it:


Integer i = (Integer) ((JpaEntityManager)em.getDelegate()).getActiveSession().executeQuery(query,args);


The query executes. You’re pretty happy, and move on. But then it gets into TEST and your SA starts pounding his chest and threatening bodily harm because there’s a slew of connections lingering open, and that just ain’t gonna work.

Anyway, the problem is right here:

em.getTransaction().begin();

You can call em.close() all you’d like, but Oracle seems to keep the connection open even after the work has been performed; and for good reason, since there’s a lingering transaction just floating out there.

So if your project is out in an environment and you start getting flooded with this error…


Caused by: java.sql.SQLException: ORA-02391: exceeded simultaneous SESSIONS_PER_USER limit


…then check all of your logic methods and make sure that all of your transactions are closed. All you need is one line at the end of the stored procedure call:


em.getTransaction().commit();


Now you know. Or know even more so. Or are reminded. Or something. Enjoy.

DISCLAIMER: I’m using JSF 1.1, Sun Implementation here. I can’t use JSF 1.2 yet because OC4J is retarded and doesn’t support those TLD’s. So take all of this griping with a grain of salt.

Quirk One – Let’s do that again!
Backing method execution works very well in the JSF version I’m used to. The binding beans work about as expected, and data transfers between layers is pretty much seamless. About that I have no complaint.

What I do have a complaint about is that it works so well that JSF seems to want to do it again and again and again. And again. I slapped a method counter on one backing bean method… an ActionEvent listener, now… and it executed six times in one page load. Farkin’ rediculous. I ended up having to set variable checks to see if the values have already been loaded, and if so just exit out. It was the only way I could get it to stop trying to do the same thing a thousand times (Though it’s still happening; the method just stops at the check).

Quirk Two – Say What?
Backing bean value is an int base data type. You’re telling me that a JSF SelectItem value can’t be binded to that? I have to bind it to a string and do a data translation? Really? We can’t support our base data types here?

I mean, it’s not hard to conquer… just a little Integer.valueOf( String ) action to go around. But reeeeeally?

Quirk Three – What’s this thingie here?
Hey, Sun? How about some strong typing. Really. It’s been a standard since Java 5 to have our collections strong-typed. Can we try and keep up here? It is so hard to declare a session object of HashMap instead of a base HashMap? Maybe I’m missing something and this is to preserve exchangability, but @SuppressWarnings("unchecked") tags get old when you need to have them everywhere.

. . . because it hasn’t seen a post since the new year.

That is all.

Happy new year. Here’s to hoping this year will be better than the last!