I see. My knowledge of NIO is pretty limited indeed: since you're
telling me it's re-designable with traditional
implementations, I see no particular issues on that side (also
because, as you described some of the core functionalities, many
features are already present in System.IO). In fact, what i did know
was that NIO was used to stream remotely, opening communication
channels between the local JVM and the remote endpoint (which could
have been another running application in the same JVM).

Coming back to Transactions: it's true that JTA is just a set of
specifications abstracted by the interfaces provided (which are easily
convertible into .NET with a custom JTA packaging), but it's also true
that .NET provides a "framework" for handling application transactions
in the same fashion as JTA.
In fact, when a developer instantiate a TransactionScope class, opens
a transactional context for th execution of the calls withing that
instance: to support this the JTA support present in neo4j should be
adapted to the specifications provided by System.Transactions, which
don't support XA nor 2PC (heavily used by neo4j).

It's true that it would be possible to create a custom transaction
namespace within the ported neo4j, but this would change the behavior
of the application: I don't know for sure, but JTA interacts with
underlying systems for the management of transactions, as
System.Transaction does; having a custom transaction mechanism would
bypass all this.


On Sun, May 3, 2009 at 2:48 PM, Johan Svensson <> wrote:
> Antonello,
> java.nio is used both for simplicity (code gets cleaner) and speed.
> The transaction packages and nioneo packages can be rewritten to use
> but that would not perform very well. Basic file operations
> needed would be:
> o read/write into/from a buffer (byte array) from/to a file
> o change position in a file followed by reading/writing at/to that position
> o flush a file making sure all changes to that file are persisted
> o file truncation is nice to have too but not absolutely needed
> -Johan
> On Sun, May 3, 2009 at 2:26 PM, Antonello Provenzano
> <> wrote:
>> Johan,
>> Thank you very much for the useful information and clarification: I
>> will dig out and come back on this later, when I will have clearer
>> view.
>> Concerning the "java.nio" issue: in .NET there's not a counter part
>> for the package. In fact, there's just the definition of the System.IO
>> namespace, which provides implementations similar to The
>> concepts before NIO are similar to the Remoting features of .NET, but
>> the architecture is really different and not always is easily
>> mappable.
>> As said in my previous email, the architectural differences between
>> the two technologies, specially after the latest developments (.NET,
>> and C# in particular, were designed to be similar to Java and helping
>> the transition of developers from one to another and reducing the
>> learning curve, but latest technologies branched out of common
>> aspects): *personally* I don't think that section would it be
>> portable.
>> Cheers.
>> Antonello
>> On Sun, May 3, 2009 at 2:10 PM, Johan Svensson <> 
>> wrote:
>>> Hi Antonello,
>>> Have a look at the neo-android component, dependency on
>>> javax.transaction has been dropped there
>>> ( by just writing
>>> empty interfaces for all the javax.transaction stuff needed.
>>> javax.transaction / JTA and X/Open are just interfaces and
>>> specifications. There is no concrete implementation or magic performed
>>> by them so removing the dependency replacing with your own empty
>>> interfaces should work. See org.neo4j.impl.transaction and
>>> org.neo4j.impl.transaction.xaframework packages for the concrete
>>> implementation of JTA, XA resources, 2PC and so on.
>>> If it is possible to port for example the
>>> package to .NET there should be no problem to port the transaction and
>>> xaframework packages to .NET (they both use java.nio to manipulate
>>> files).
>>> Regards,
>>> -Johan
> _______________________________________________
> Neo mailing list
Neo mailing list

Reply via email to