Andy, Thanks for this wonderful note. It would make a fantastic blog post! These sorts of testimonials do amazing things for the growth of the project.
I'll have a look at your patches -- hadn't actually noticed them in JIRA. Feel free to send a note to the dev list anytime you have something for review. On the datasource topic, there's a new @DataSourceDefinition annotation in Java EE 6. You interested in working on it? -David On May 14, 2010, at 2:38 AM, Andy wrote: > 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. >
