XADisk behaviour with non XADisk disk access

[malte....@googlemail.com]

Hi!

we have a library in our project that is out of our scope. It's a checking tool for format and value checks of a xml file. It's result is another xml file that contains the check results.
The library does rely on plain Java File IO.

like:
1. Session.move(dirx, diry)
2. XMLChecker.check(dirX/file.xml)
2. Session.commit()

XA Disk seemed like a good library for our project because we did not have to implement our own locking mechanisms for file IO. But We noticed, that there are IOs that we can't redirect to XA Disk.

How do the various Methods in XA Disk behave if non XA Disk IO occures?
Do Changes in the file system will be reflected even if a Transaction has started?

Thanks in advance.

[Nitin Verma]

Hi Malte,

Sorry for delay in my response.

XADisk can only co-ordinate concurrent accesses to same files/directories if they (all accesses) are through the xadisk instance - for this it uses its own in-memory locks. And if some other application makes some changes to the file-system (without xadisk), xadisk should be able to read those changes, unless the same files/directories are modified (in which case there can be strange outputs) by xadisk transaction.

With a quick thought, I think one trick to combine a non-xadisk io system with xadisk transaction is to let the non-xadisk io happen on a temporary location, and let xadisk transactions move those changes to the actual location, to make the "actual change" part of xadisk transaction. You can check how/if it is applicable for your case.

Please let me know if I could answer your question.

Thanks,
Nitin

[malte....@googlemail.com]

Hi Nitin,

no problem with the delay. That's fine!

Thanks for that answer. It's good to know that XA Disk might handle files that are modified out of XA Disk - if xa disk does only read access to that files.

I thought of creating files in a temporary directory without xa and moving them in the directories that are managed by XA Disk by XA Disk too. But i was concerned about the performance impact of this step and it would have left a unsatisfying bad feeling.

We decided to not mix up non transactional stuff with transactional stuff in this case and take a step back. We implemented a lock system by ourselfs that hopefully will be sufficient. Even if it does not supports rollbacks for the time being. 

In our case it's not XA Disk fault but the rigid architecture of the checking tool we have to use.

regards,

Malte