See my comments inline:

On Sun, May 3, 2009 at 4:05 PM, Antonello Provenzano
<antone...@deveel.com> wrote:
> Johan,
>
> I see. My knowledge of NIO is pretty limited indeed: since you're
> telling me it's re-designable with traditional java.io
> 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).
>

Yes, but we only use the native I/O part for files. Simply put, we
want to avoid the extra copy of buffers that takes place from outside
jvm memory to jvm buffers. NIO allows us to allocation direct buffers
(that are allocated and managed outside the normal java heap). I also
like the design of the nio package with channels and it is good that
you can use the same interfaces to shuffle data over the network but
Neo does not use those features (yet).

> 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 should be possible to port Neo4j's transaction handling to support
.NET's way of handling transactions. Neo will only make use of 2PC if
there are multiple resources participating in the transaction. If you
only use Neo and nothing else all commits will be optimized one phase
commits.

How would .NET handle a transaction that would like to modify
something in two different databases in the same transactional
context? That is what we use the two phase commit protocol for but if
you only use Neo4j there is only one resources enlisted in the
transaction so then it is not needed.

> 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.
>

Yes, also it might be possible to just write some glue code between
the .NET TransactionScope and the NeoService.beginTx() &
org.neo4j.api.core.Transaction classes. If all you need is single
resource, begin,commit and rollback it would be much easier to
integrate there and just do a straightforward port of the transaction
package.

Regards,
Johan

> Cheers.
> Antonello
>
>
> On Sun, May 3, 2009 at 2:48 PM, Johan Svensson <jo...@neotechnology.com> 
> 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
>> java.io 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
>> <antone...@deveel.com> 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 java.io. 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 <jo...@neotechnology.com> 
>>> wrote:
>>>> Hi Antonello,
>>>>
>>>> Have a look at the neo-android component, dependency on
>>>> javax.transaction has been dropped there
>>>> (https://svn.neo4j.org/components/neo-android/trunk/) 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 org.neo4j.impl.nioneo.store
>>>> 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
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to