Hi All,
Just to let you know where I am with OpenEJB in a real world application.
My environment is 32 and 64bit Vista/7 with JDK 32/64 1.6.19 in all
combination's (ie. 32bit JDK on 64bit OS etc.)
I am working off the trunk with a few changes - all JIRA'd, but
specifically ActiveMQ RA on AMQ 5.4, Quartz 1.8.0 as a Service (using
the service.xml) and the TempClassLoader.
I carefully analyze changes to the trunk before pushing to my local
build, but currently have no issues except for the aforementioned
changes / additions.
My client project consists of an embedded OpenEJB and Hibernate using
the Derby 10.3 branch - This acts through an API as a local cache for an
AOI machine system, which also gives the system a critical offline
capability during operation. The client uses a combination of lazy and
real time replication of data to a remote server through a daisy chain
API - all controlled by AMQ. I use Quartz jobs for periodical monitoring
and maintenance of data, and gain access to the Scheduler over JNDI - so
not really using the container. A client may operate on several AOI
machines - Each machine is represented by a specific application.jar
context in OpenEJB that uses a separate database instance. This gives me
the ability to provide a version-ed application on a per machine basis
that can be dynamically loaded and unloaded as required - but still uses
the same code base.
The only hurdle I really had to overcome in OpenEJB was to write my own
deployer due to the necessity of having to dynamically deploy and
undeploy data sources for the application persistence units - something
that I felt was missing from the first day I started using OpenEJB.
The server is a remote OpenEJB instance which hosts an identical
application.jar per machine, but uses a replicated PostgreSQL for
backend storage. The daisy chain API acts as the replication bridge
between the client and server applications. The real benefit of using
OpenEJB has been the ability to create a client and server application
that are virtually identical. The server has an additional application
that monitors, maintains and provides information on all currently
loaded machine applications.
The storage solution development has just over a thousand unit tests
(constantly growing) that test online and offline storage and
replication. The local cache application is providing a good response
with over a terabyte of cached data in Derby. The server has been stress
tested up to 20TB running 20 application instances, but in the real
world we are unlikely to have more than 4 machines.
It was my initial plan to just use OpenEJB for testing, and then JBoss
for the real world application. Everything is running so well on OpenEJB
that that plan has changed and I am going into production with OpenEJB -
at least where transactional clustering is not a requirement.
Thanks for a great product - and branch or not, I will be using OpenEJB
for many years to come!
Best regards,
Andy.
PS. I am always looking for and eager to use the latest iteration of
many projects around OpenEJB, so ActiveMQ , Quartz and Derby trunks have
been heavily tested by myself during development - and I have found and
contributed to the resolution of several bugs in all of them. I know
what I currently have has proven itself stable in our relatively
demanding environment.
