|
[
Permlink
| « Hide
]
Massimo Lusetti added a comment - 04/Aug/06 04:20 AM
The patch apply from file provider project root
The error caused by testSend method in FileConnectorTestCase is related to the fact of FileResourceManager non completely initialized, since the initialization of FileResourceManager (from commons-transaction) is done in the doInitialize() method on the connector i don't understand why the testSend method should fail and the testDispatch method not.
new ver of the same patches getting read of FileSequencer
One question: did you take any look at the classes in org.mule.util.file? It contains the beginnings of a supposedly transactional FileManager, but looks unfinished and is nowhere used (~ probably dead code) but I was wondering if you had looked at it maybe for integration with the regular Mule TX handling.
Not at all, I wasn't aware of their existance, if gnt@ is still around and would like to introduce that classes that would be very appreciated, i'm more then willing to drop or adjust the current integration with commons-transaction.
Thanks Holger for pointing, having file tx integrated with regular Mule TX is a big plus. I doubt that Guillaume has the time or interest, he's working for LogicBlaze (the company behind ServiceMix). In any case there's no reason to drop your patch at all! The code in org.mule.util.file is very much incomplete, but maybe you can have a look how it might be used together with your commons-transactions file stuff - maybe as an XA wrapper on top, or as a kind of "nested transaction".
To me reliable non-XA file handling is more important than flaky XA support that claims to be transactional but really isn't. Andrew, Holger
Before i start digging through the code i would like to have your opinion on the following question. The comments on the org.mule.util.xa and org.mule.util.file packages And as a general hint, which is the best place where to place a single My feeling is that we should duplicate code from commons-tx if a) the project is being maintained and b) that it works. I would prefer to add the dependency to the core and remove uncessary TX code from Mule.
As for the Singleton to be shared between connectors, that could be located on the TransactionCoordination object (which is a signleton used by transation support in Mule) I think we'll need to address the Mule home-roled Queue Manager stuff to use the new Java Queue API, maybe we could also migrate the transaction code to commons-tx as the code is so similar anyway Just as reference: new Queues are MULE-710
moving this off 1.3rc5 since it has to much impact. even if we only have CT in file-provider this is too much of a change for now, since if CT really goes into core we would have to change it again anyway. Maybe for 1.3 in file-provider only and then 1.4 overall but that depends on how quickly we get the TXManager/Queues done as per Ross' comment.
I have strong feeling about the patch to be completely broken, my mistake on understanding how CT is actually working, glad anybody have had a look at it
 I'm about to starting new discussion on dev@ on this. This completely replace the previous one.
Now we will get a FileResourceManager per endpoint address which will handle all transaction for the particular directory. On the receiving part of the transport we need to find a method to get a "common root path" for the readDirectory and the moveDirectory (if moveToDirectory exist) since the FileResourceManager needs a common prefix (a directory called storeDir by FRM itself) which it will keep under its total control while outside that particular path it cannot operate, let think about it as a chroot environment. So if a receiving endpoint address is /tmp/foo and has a moveToDirectory property value of /tmp/bar the common root path for the FRM will be /tmp and we will have two relative prefix for endpoint address (foo/) and for moveToDirectory (bar/). Dispatcher are not affected by this boring issue. Note about tests: Let's help make c-tx better: http://issues.apache.org/jira/browse/TRANSACTION-12
  News:
http://issues.apache.org/jira/browse/TRANSACTION-13 http://forum.springframework.org/showthread.php?t=32704
JTA integration might come in the future, this might help. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Patch submission
Open
Minor
File provider improvements for file transactions
