If your project is also using XADisk and you want to share the excitement, send your story here
Our group runs one of the largest payment processing infrastructures in the world. For many of these payment flows, we receive files of instructions from our clients, run them through a series of high-speed workflow engines running on Java EE servers, and then send them out to various clearings around the globe for execution. Using XADisk, we've been able to integrate file handling into our distributed transactions covering MQ, Tibco, the Java app servers, and the Oracle databases. This design has improved the overall resiliency of the solution and reduced the impact of various issues we've had with processing. All in all, XADisk fills a critical need in the java transaction space and I would recommend anyone with mission-critical processing consider it as part of their solution suite.
Project Domain: Banking / Payment Processing
Our web application is installed in a public institution, accepting messages from companies around Europe, with an expected load in the order of 6 to 7 digits per year. It is deployed on Weblogic 10.3, acessing XADisk via JNDI as a JCA resource and using Spring to bind it all together. Background deamons poll an incoming upload folder before further processing by back-end systems. Since the file messages are mission-critical and must not be "lost", we make XADisk participate in the distributed transaction, ensuring that the status of each file is always consistent across the filesystem and the underlying database.
Project Domain: Government/Pharmaceuticals
We have developed a J2EE based Server component for Synchronization of data between multiple Semi Conductor Manufacturing Tools. We have developed this application as a product which can be installed at client sites based on the license type. The Server application is built on JMS/JCR Repository/XADisk/Database. The communication between the tools and the Server is through MQ. We have used XADisk for implementing XA Transaction at File System level. We have deployed XADisk and JCR Repository as JCA Resources. Our application now handles upto 1 Gigabyte of data pushed from the client tools. Integrating with XADisk solved our XA Transaction implementation at File System level. That was one of our main requirement when we started the project.
Project Domain: Semi Conductor Manufacturing
We used XADisk in GlassFish 3.0.1 as a JCA resource adapter. The requirement was to delete several files on a UNIX based system along with some records in MySQL. The file paths were associated with the records in the database, and they had to be handled transactionally, which means that the deletion had to succeed for files and database records as well. Even though XADisk had only a beta version at that time, it solved our problems perfectly.
We were faced with the need to manipulate and store large documents in a high throughput, mission critical, EJB 3.0 environment, and needed a safe way to ensure that temporary files were destroyed upon commit or rollback, and that permanent result files were only persisted visibly from the application when the transaction was committed to ensure synchronization with database resources. This was especially important considering that once the execution flow had returned from our code base to the application server stack, there was still a possibility of a rollback or timeout that could not be anticipated or handled. This forced us to look for a JCA connector approach to interface with the file system. After much searching, XADisk was the clear front runner in terms of its comprehensive consideration of transactionality when creating/manipulating/moving/deleting files.
Project Domain: Government/Security
We developed a platform which runs on an application server picking up large amounts of documents (image-files) stored in compressed containers from the file system and prepares/transforms them during our workflow processes steered by a user interface. While the meta-data gets stored in a relational database (via JDBC) we wanted to keep the binary data (i.e.: the actual image-files) separated in a custom file-store. The challenge we were facing was that either the whole content of a container (up to several hundred of files) gets imported into our platform or nothing at all (e.g. rejection in case of duplicates, etc.). While this wasn’t much of a problem regarding the relational database, the complexity introduced by making the file-system fail-safe and developing a mechanism to handle rollbacks of large amount of files was way too high. This is where we came across XADisk which solved all our problems in a breeze by just deploying it into our platform as a XAResource which afterwards could be used to work in distributed transactions spanning across the relational database and the file-store (i.e.: file-system). While this already saved us a lot of effort this wouldn’t be much of a benefit without having proper support available in case of problems. We would like to point out that the author of this project is always helpful in responding and solving our questions in the XADisk Google groups.
We have used XADisk in two applications: the first one is a medical-archiving software that receives diagnostical images from radiology. It is a db-less application that needs to persist, in a single transaction, thousands of files (~130GB per day), process and compress them. We have used Tomcat as servlet container and XADisk for these standalone (non-distributed) transactions with files.
The second one is an enterprise application that runs on Glassfish Application Server (Solaris OS). Our need is to send some files, update a DB table and send a JMS message in a single (distributed) transaction. We have deployed XADisk as JCA Resource Adapter and used JTA (EJB BMT transaction) to accomplish this goal.
Project Domain: Government/Digital preservation
We used XADisk as a main component in the file repository used by our application platform. Thanks to it's support for transactions we can easily keep the repository consistent and at the same time integrate with external systems and Java libraries which require direct access to files. We find XADisk very reliable and easy to integrate with enterprise applications.
Institute of Spatial and Cadastral Systems (www.ispik.pl)
Our application maintains a conversation with citizens over legal matters via different channels. We used XADisk along with Spring Batch and Atomikos to process huge number of "mails" from different incoming platforms maintaining the state of the conversation along with all required attachments. XADisk helped us integrate file system and database to have a single transaction.
Project Domain: eGovernment
We integrated XADisk with our web application for quality control system. In most cases, people need to upload images, proofs, spreadsheets and important measurements all at once. We needed distributed transactions and XADisk is the one we have been looking for. It just solved our biggest problem - the need for JTA-compliant file transactions.
Our application needs to process incoming messages, extract some data out of them, persist the data to Database, and then the reciprocal message is sent back to an external application. The message channel can be a mq socket or a file socket. As long as our application was just a web application there was no problem with file system access. Now the necessity of going to JEE platform arises. While mq-messaging is becoming simpler with JEE the file socket messaging didn’t seem so. And also we couldn’t afford to refuse legacy file communication with external systems since still most of systems of our interest use that kind of communication. I had to do quite a lot of web surfing during which I found some “toy” JCA examples working with file system. Then I encountered XADisk, which turns out to be surprisingly mature product.
We have built an Enterprise Web Services Testing Platform (Prowess/paninisoftware.com) which needed to store its Repository in a file system (in addition to other options). In order to implement a concurrent and transactional file system repository, we required a robust file system transaction framework on top of Java IO API. After evaluating multiple options we narrowed down to XADisk which provides a simple API and configuration. We could easily integrate/inject XADisk resources into the platform architecture using Spring. Inspite of its open source nature, the XADisk team responded quickly to our queries.
Our application needs to process incoming files, extract some data out of them, persist the data to MS SqlServer Database, and then delete the processed files. By integrating XADisk with JBoss, with its JTA and JCA support, we could do this complete flow in a single transaction.
Project Domain: Financial Services