Read Time:3 Minute, 31 Second
The project I have been working on lately requires me to move out of my comfort zone of pure Python, and focus on something more. Unfortunately, I am stuck with certain requirements from the company:
- My application must be deployable to Glassfish 3.1
- Which means it must use Java EE 6
- …And Java SE 7
- I must be able to access our Oracle databases.
- And it must be packageable as a WAR file.
- I must define my database connections through a glassfish-resources.xml file.
Well, this is just plain annoying. I want to code Python, not Java. So…. Jython comes to the rescue. Unfortunately, it is still stuck in the 2.7 era of Python (the rest of my code is running 3.5). However, Python is Python, right?
First, I needed to get a working framework to use to develop in Jython for the web. I checked the automatic knee-jerk response of “Django”, and it was sorely lacking in an Oracle DB interface through JDBC, which I would need. So, I picked Flask, since it doesn’t have a database API it comes with.
Next, I needed a DB system I could use. I checked my go-to package of SQLAlchemy, which also was sorely lacking in a driver for Oracle DB over JDBC. So I ditched SQLAlchemy, and was getting frustrated, but then remembered, Java EE comes with a nice Object Relational Mapper API, JPA 2.0. And, Oracle (Java/Glassfish) should be able to talk to Oracle (DB) fairly well. So… I built my JPA entities, and got Jython to be able to use it.
Next, the system I am working on will be replacing another already existing system. The existing system has a problem where it is doing a depth-first calculation on a multi-level tree structure defined in a handful of tables in the database. If that doesn’t sound painfully resource-expensive, then I did not explain it very well. As of right now, there have been a handful of cases where the DBAs had to kill one of the running processes for this system in order to save the DB from coming to a screeching halt.
So, I decided to implement a NoSQL Graph DB to build the tree, and be able to easily update it. I finally settled on Bitsy, which is an implementation of the Apache Tinkerpop Blueprints 2.4.0 API, which is a very nice Graph DB system.
So I started building a system that would load the graph from the Oracle DB. That worked. Then I tried querying it to see if the graph was loaded. And that’s when the fun began. Apparently Bitsy absolutely requires only one connection is opened to the DB at any one time, and the only way to free that is through using the shutdown() method from the graph.
So I had to build an application context level variable for Flask that would make the graph connection, and then also would shut it down when the application context was finished. And I hat it working, in a way. The problem was I was getting confused between what Flask called “application context”, and what Java Servlets called “application context”. The Java Servlets keep the context open once it is accessed, until the system is shut down. Flask however opens and closes application contexts regularly. And this caused a clash, if I tried accessing the graph from two browsers at the same time, one would simply not work. So, that simply did not do for my needs.
However, Java EE 6 has the concept of a Singleton Enterprise Java Bean, which looked to be exactly what I needed, and I built the bean to make the connection (at application startup) and hold it open, and it would then do the shutdown() method when the bean was closed, like if the glassfish instance is restarted or the WAR file is reinstalled. And I modified my Flask application context variable to make a connection to the Java Bean to get access to the Graph DB connection instance.
All in all, this works together beautifully now.
Can’t show any code this time, but I might be able to in the future.