/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.

Around the time of Kubuntu 9.04, I was pretty annoyed. I’ve read plenty about how Kubuntu is pretty much the bastard child of KDE and Ubuntu and received very little love insofar as development time, effort, energy, etc. 9.04, I believed, showed this to an extreme. It was buggy, and a lot of these bugs showed up just in the process of ordinary use. These are just my own personal examples:

* Unstable OpenGL Desktop acceleration (I typically ran without effects 24/7)
* Poor Suspend-to-RAM recovery. 1 in 3 wake-ups would hard-lock the system
* Power Management daemon hardlocks system if plugged in during Suspend-to-RAM
* Crash-happy OpenOffice Writer
* KDM crashes

This is in addition to other minor bugs, such as libpam-mount being flaky and KNetworkManager being unreliable (I ended up using WICD, which was a godsend).

Thankfully, 9.10 redeemed Kubuntu for the year.

I switched over around Release Candidate 2, and even that proved more reliable than 9.04. Power management seems much tighter. I’ve had only 1 hardlock in many, many Suspend-to-RAM instances. I can plug the laptop in when it’s in sleep mode. The OpenOffice integration with KDE is nice, though it did decide to take a nosedive a few days ago; that has yet to repeat, however (**knocks on wood**).

KNetworkManager still pisses me off. The application seems to be married to KWallet, an app that I absolutely hate. If I turn off the wallet system, KNetworkManager is neutered. In addition, it did not auto-detect my wireless network’s encryption method… something I’ve come to expect these days. Easy to fix once I realized the problem, but still surprising.

I do believe they gimped WICD with this release… though I can’t prove it. That service does not seem to recover from Suspend-to-RAM. It loses all ability to scan for wireless networks and refuses to reconnect when the laptop comes back up. Maybe this is just my own personal experience, but I’ve put up with the KWallet pestering up until now (It only insists on the password once per login and doesn’t ask again coming out of sleep).

The option to automagically encrypt home directories was a beautiful addition, and pretty much nullified any need for that other article I posted a while back. Given this OS is on my writing laptop, I jumped all over this option. It may cause problems at reinstall time if I ever need to just upgrade the OS. I keep my /home root on a separate disk partition, so I can upgrade the OS without worrying about my preferences and files. This option stores everything in a /home/.usernamePrivate file and mounts the file at log-in time. I’m sure this will cause problems later on, but I can worry about that later.

I discovered the Globe desktop integration as part of this release. Maybe I’m just behind in the times, but this is a nice feature. Pretty eye candy, doesn’t require OpenGL acceleration, and any kind of dynamic desktop is a boost when showing off the operating system to the Windows babies at my office.

Overall, not a bad release thus far. I believe I’m pleased, and may not have to jump on the upgrade bandwagon come next April.

Ever since picking up my laptop, I have had a concern about having my stories on such a portable machine. I bought myself a Bauer-like man-purse, so this laptop basically goes everywhere I do. It’s convenient with the lappy being so light, but it IS a laptop. It’s not hard to take, mount the drive on an external system, and voila… all my stuff is in the open.

I’ve been keeping an eye out for a solution, and I think I found one after some Googlin’.

Some details:
• OS: Debian-based distribution
• Kernel:2.6.28-15-generic
• Encryption used: AES
• Prerequisite Packages:
  • loop-aes-utils

  Create an Encrypted Filesystem
  The first thing to do is create a loopable filesystem that can be mounted by the kernel. Find some place on your filesystem that’s nice and out of the way… or that’s plainly obvious, since we are using encryption. I threw mine in my Documents folder. Nice and hidden where absolutely everyone will find it. But meh.

  Create the filesystem image with the following command:
  dd if=/dev/urandom of=imageName.img bs=1M count=100


  According to the article, using /dev/urandom makes the file a bit more indistinguishable from other used filesystem sectors, but /dev/zero works fine as well.

  Next, assign the filesystem image to a loopback device:

  sudo losetup -e aes /dev/loop0 /path/to/imageName.img

  If the kernel complains about invalid arguments, make sure that your encryption libraries are installed (IE: AES, Twofish, etc) and that the modules are loaded. If not, run the following command:

  sudo modprobe aes

  Keep in mind that for AES, you’ll need a password of 20 characters.

  Now that the image is associated with a loopback device, create the filesystem:

  sudo mkfs -t ext4 /dev/loop0

  Mount the Filesystem
  Now that you’ve created your filesystem image, it needs to be properly mounted in order to be used. You can do this by passing the encryption argument to the mount command:

  mount -o loop,encryption=aes /path/to/imageName.img /path/to/mount

  Using this Filesystem
  My filesystem will hold some rather sensitive data… my work. Mostly I’ll toss my stories in there. We’ll see what else I plug in. A nice feature will be to tie the mounting process in with the system log-in. We’ll see if that works out.

  I did throw a nice li’l launcher on my taskbar with a lock icon. Makes it feel all nice and special.

  RESOURCE: http://www.linuxjournal.com/article/6481

It started with Hibernate, but really did not stay there long. Moving to persistence frameworks was really a no-brainer: our method of instantiating objects from the database was bulky, inefficient, and prone to problems. Plus, everybody and their brother wrote the data loading in a completely different manner, and let me tell you, the way that some of those methods were written would make your eyes explode.

Hibernate offered at least some relief in that regard. Plus it allowed us to migrate to a connection pool, even though that never made its way into production. Since my team abhors all things easy, we have to provide specific credentialing in order to log in and perform business logic. Generic connection pools need not apply, but after some patching, I at least got Hibernate to the point where it could use statically-instantiated connections.

Fast forward in time to JPA and EclipseLink.

Much of the same restrictions were there, but there was a new catch that nearly brought my team to its knees.

EntityManager.clear();

Don’t use it. I know it looks all innocent and such. What possible harm could it cause? I mean come on, if you’re looking to use the most recent data, then what better way is there to ensure it’s shown than to clear out the Entity Manager’s persistence cache and re-fetch live data?

It shocked me to find out this single statement was responsible for bringing down the entire application. It was used after several action methods to clear the cache and display updated data. I had advised my team to use parental refreshes that then filter down to the child objects, but because this statement was far easier than actually fetching/instantiating the parent object, well, it spread like wildfire.

I could pull an “I told you so”, but after 3 weeks of hell at the office, I couldn’t care less anymore.

So lesson learned.