Re: [Neo] Event framework has landed
Hi Mattias, thanks for your replies, finally getting back myself. Some clarifications about questions 2 and 3, getting data in and out of the transaction: What I am looking for is a way to do something like this: int revision = transaction.finish(commitMessage, userId); I've actually got this working by using a TransactionWrapper which intercepts these calls and puts the data in a global Thread map. The commit message and user id are then read out from the map by the transaction event handler. This works fine, but passing around the data in a global data structure just has an awful code smell. While another way would be to have the service layer read out the current revision and write the commit message itself etc. this smells just as bad IMHO with duplicated code and an unclear calling chain. So what I am looking for is a way to pass the data to the transaction as explained above, or maybe also something like: transaction.setAttribute(message, my commit message); tx.finish(); int revision = transaction.getAttribute(revision); Now I see my first snippet is quite specific to implementing a versioning system, but the later might be useful for other cases too. Is there any way to do this or is anything planned? Now that I've actually wrote about it my solution doesn't sound so bad really :) Best regards, Georg On 03.05.2010 17:03, Mattias Persson wrote: 2010/5/1 Georg M. Sorstgeorgso...@gmx.de Hi Mattias, hi list that's just what I've been looking for, congratulations on the amazing progress you are making on Neo4j! I am actually trying to use the TransactionEventHandler to implement automatic versioning similar to what was discussed a while ago. The beforeCommit() handler seems like a perfect fit and provides all the data I need. Still, I have one problem: in beforeCommit() I fetch and increment a revision number that's stored in a special node and use that number to build the current revision structure. This brings up a few questions: 1. How atomic are Neo4j commits? Will two concurrent commits interfere when getting and incrementing the revision number? Transactions are atomic, but if transaction T1 reads a value and modifies it, but before it modifies it T2 reads the same value in the intent to modify it, there's a possibility that T1 and T2 will read the same value. And if they both increment the value they both will set it to the same value (which would not be the intended behavior). What you would need to do is to make sure T1 has a write-lock on the node which carries this revision property, that way T2 will have to wait until T1 is committed and will read the correct value. There's no nice way of locking a node other than setting/removing a property or creating/deleting relationships on it, so I'd say an ugly, but perfectly working way would be to do something like this: nodeWithRevision.removeProperty( a dummy property ); int counter = (Integer) nodeWithRevision.getProperty( revision ); so that neo4j is forced to take a write-lock on that node before getting the counter property. A nicer way will be exposed soon to do this instead! 2. How can I return the revision number from the TransactionEventHandler so I can use it in the caller (my service classes in this case)? I'd say it'd be better if the service classes could read the revision from the node which has the revision directly, that way you'd always get the committed value. Maybe your handler could have a getRevision() method which reads the revision property from that revision node. 3. The caller should be able to pass data to the transaction, for now just the commit message. Of course I can temporarily store this in a node or attach it to the thread etc. but that just seems wrong. How can I do this right? I don't know what you mean by pass data to the transaction if it would not be to store something in the graph, f.ex. a property on a node. What exactly do you mean by that? Thanks and best regards, Georg On 27.04.2010 10:15, Mattias Persson wrote: Hi everyone! I'm quite pleased to announce that the new event framework has been committed in kernel 1.1-SNAPSHOT. After feedback from you guys the framework got quite small and cosy. Here's a summary. *TransactionEventHandler* can be registered at a GraphDatabaseService and will thereafter recieve diffs of modifications made in each transaction before and after they are committed. The transaction can still be modified in beforeCommit() and that method can also throw an exception to prevent the transaction from committing, causing a TransactionFailureException to be thrown from the code which is committing the transaction. *KernelEventHandler* can be registered at a GraphDatabaseService and will receive notifications about when a shutdown is about to occur for the GraphhDatabaseService instance. It will also receive notifications about kernel panics which is a state which the
Re: [Neo] Event framework has landed
All right, I see what you mean. You're basically wondering if Neo4j already has implemented some of the functionality you're trying to build, right? No, there's no such feature, but you could build it yourself. I'll give you an example of a solution. Say you have a root node to represent the revisions. That root node has a revision counter (which is the last committed revision) and a linked list of nodes representing the commits, containing f.ex. a commit message. I just added a class which manages a linked list of nodes in the http://components.neo4j.org/neo4j-utils/ component, see the NodeStack class. You can use that or see how it's implemented. // Create the root node Node rootNode = graphDb.createNode(); graphDb.getReferenceNode().createRelationshipTo( rootNode, RelTypes.REVISION_ROOT ); NodeStack revisionList = new NodeStack( rootNode, RelTypes.REVISION_LIST ); // Add a revision Node revisionNode = revisionList.push(); int revision = (Integer) rootNode.getProperty( last_commited_revision, 0 ); rootNode.setProperty( last_commited_revision, ++revision ); revisionNode.setProperty( message, My commit message ); revisionNode.setProperty( revision, revision ); // You could also index the revisions with LuceneIndexService. The Add a revision code could be wrapped in a TransactionWrapper (as you've already done) so that the revisions are stored right there and then, not in the handler. That would be my bet. 2010/5/10 Georg M. Sorst georgso...@gmx.de Hi Mattias, thanks for your replies, finally getting back myself. Some clarifications about questions 2 and 3, getting data in and out of the transaction: What I am looking for is a way to do something like this: int revision = transaction.finish(commitMessage, userId); I've actually got this working by using a TransactionWrapper which intercepts these calls and puts the data in a global Thread map. The commit message and user id are then read out from the map by the transaction event handler. This works fine, but passing around the data in a global data structure just has an awful code smell. While another way would be to have the service layer read out the current revision and write the commit message itself etc. this smells just as bad IMHO with duplicated code and an unclear calling chain. So what I am looking for is a way to pass the data to the transaction as explained above, or maybe also something like: transaction.setAttribute(message, my commit message); tx.finish(); int revision = transaction.getAttribute(revision); Now I see my first snippet is quite specific to implementing a versioning system, but the later might be useful for other cases too. Is there any way to do this or is anything planned? Now that I've actually wrote about it my solution doesn't sound so bad really :) Best regards, Georg On 03.05.2010 17:03, Mattias Persson wrote: 2010/5/1 Georg M. Sorstgeorgso...@gmx.de Hi Mattias, hi list that's just what I've been looking for, congratulations on the amazing progress you are making on Neo4j! I am actually trying to use the TransactionEventHandler to implement automatic versioning similar to what was discussed a while ago. The beforeCommit() handler seems like a perfect fit and provides all the data I need. Still, I have one problem: in beforeCommit() I fetch and increment a revision number that's stored in a special node and use that number to build the current revision structure. This brings up a few questions: 1. How atomic are Neo4j commits? Will two concurrent commits interfere when getting and incrementing the revision number? Transactions are atomic, but if transaction T1 reads a value and modifies it, but before it modifies it T2 reads the same value in the intent to modify it, there's a possibility that T1 and T2 will read the same value. And if they both increment the value they both will set it to the same value (which would not be the intended behavior). What you would need to do is to make sure T1 has a write-lock on the node which carries this revision property, that way T2 will have to wait until T1 is committed and will read the correct value. There's no nice way of locking a node other than setting/removing a property or creating/deleting relationships on it, so I'd say an ugly, but perfectly working way would be to do something like this: nodeWithRevision.removeProperty( a dummy property ); int counter = (Integer) nodeWithRevision.getProperty( revision ); so that neo4j is forced to take a write-lock on that node before getting the counter property. A nicer way will be exposed soon to do this instead! 2. How can I return the revision number from the TransactionEventHandler so I can use it in the caller (my service classes in this case)? I'd say it'd be better if the service classes could read the revision from the node which has the revision directly, that way you'd
Re: [Neo] Event framework has landed
Hi Mattias, this looks quite similar to what I have done so I guess I'm on the right track :) Thanks again and best regards, Georg On 10.05.2010 12:59, Mattias Persson wrote: All right, I see what you mean. You're basically wondering if Neo4j already has implemented some of the functionality you're trying to build, right? No, there's no such feature, but you could build it yourself. I'll give you an example of a solution. Say you have a root node to represent the revisions. That root node has a revision counter (which is the last committed revision) and a linked list of nodes representing the commits, containing f.ex. a commit message. I just added a class which manages a linked list of nodes in the http://components.neo4j.org/neo4j-utils/ component, see the NodeStack class. You can use that or see how it's implemented. // Create the root node Node rootNode = graphDb.createNode(); graphDb.getReferenceNode().createRelationshipTo( rootNode, RelTypes.REVISION_ROOT ); NodeStack revisionList = new NodeStack( rootNode, RelTypes.REVISION_LIST ); // Add a revision Node revisionNode = revisionList.push(); int revision = (Integer) rootNode.getProperty( last_commited_revision, 0 ); rootNode.setProperty( last_commited_revision, ++revision ); revisionNode.setProperty( message, My commit message ); revisionNode.setProperty( revision, revision ); // You could also index the revisions with LuceneIndexService. The Add a revision code could be wrapped in a TransactionWrapper (as you've already done) so that the revisions are stored right there and then, not in the handler. That would be my bet. 2010/5/10 Georg M. Sorst georgso...@gmx.de mailto:georgso...@gmx.de Hi Mattias, thanks for your replies, finally getting back myself. Some clarifications about questions 2 and 3, getting data in and out of the transaction: What I am looking for is a way to do something like this: int revision = transaction.finish(commitMessage, userId); I've actually got this working by using a TransactionWrapper which intercepts these calls and puts the data in a global Thread map. The commit message and user id are then read out from the map by the transaction event handler. This works fine, but passing around the data in a global data structure just has an awful code smell. While another way would be to have the service layer read out the current revision and write the commit message itself etc. this smells just as bad IMHO with duplicated code and an unclear calling chain. So what I am looking for is a way to pass the data to the transaction as explained above, or maybe also something like: transaction.setAttribute(message, my commit message); tx.finish(); int revision = transaction.getAttribute(revision); Now I see my first snippet is quite specific to implementing a versioning system, but the later might be useful for other cases too. Is there any way to do this or is anything planned? Now that I've actually wrote about it my solution doesn't sound so bad really :) Best regards, Georg On 03.05.2010 17:03, Mattias Persson wrote: 2010/5/1 Georg M. Sorstgeorgso...@gmx.de mailto:georgso...@gmx.de Hi Mattias, hi list that's just what I've been looking for, congratulations on the amazing progress you are making on Neo4j! I am actually trying to use the TransactionEventHandler to implement automatic versioning similar to what was discussed a while ago. The beforeCommit() handler seems like a perfect fit and provides all the data I need. Still, I have one problem: in beforeCommit() I fetch and increment a revision number that's stored in a special node and use that number to build the current revision structure. This brings up a few questions: 1. How atomic are Neo4j commits? Will two concurrent commits interfere when getting and incrementing the revision number? Transactions are atomic, but if transaction T1 reads a value and modifies it, but before it modifies it T2 reads the same value in the intent to modify it, there's a possibility that T1 and T2 will read the same value. And if they both increment the value they both will set it to the same value (which would not be the intended behavior). What you would need to do is to make sure T1 has a write-lock on the node which carries this revision property, that way T2 will have to wait until T1 is committed and will read the correct value.
Re: [Neo] Event framework has landed
Great! 2010/5/10 Georg M. Sorst georgso...@gmx.de Hi Mattias, this looks quite similar to what I have done so I guess I'm on the right track :) Thanks again and best regards, Georg On 10.05.2010 12:59, Mattias Persson wrote: All right, I see what you mean. You're basically wondering if Neo4j already has implemented some of the functionality you're trying to build, right? No, there's no such feature, but you could build it yourself. I'll give you an example of a solution. Say you have a root node to represent the revisions. That root node has a revision counter (which is the last committed revision) and a linked list of nodes representing the commits, containing f.ex. a commit message. I just added a class which manages a linked list of nodes in the http://components.neo4j.org/neo4j-utils/ component, see the NodeStack class. You can use that or see how it's implemented. // Create the root node Node rootNode = graphDb.createNode(); graphDb.getReferenceNode().createRelationshipTo( rootNode, RelTypes.REVISION_ROOT ); NodeStack revisionList = new NodeStack( rootNode, RelTypes.REVISION_LIST ); // Add a revision Node revisionNode = revisionList.push(); int revision = (Integer) rootNode.getProperty( last_commited_revision, 0 ); rootNode.setProperty( last_commited_revision, ++revision ); revisionNode.setProperty( message, My commit message ); revisionNode.setProperty( revision, revision ); // You could also index the revisions with LuceneIndexService. The Add a revision code could be wrapped in a TransactionWrapper (as you've already done) so that the revisions are stored right there and then, not in the handler. That would be my bet. 2010/5/10 Georg M. Sorst georgso...@gmx.de mailto:georgso...@gmx.de Hi Mattias, thanks for your replies, finally getting back myself. Some clarifications about questions 2 and 3, getting data in and out of the transaction: What I am looking for is a way to do something like this: int revision = transaction.finish(commitMessage, userId); I've actually got this working by using a TransactionWrapper which intercepts these calls and puts the data in a global Thread map. The commit message and user id are then read out from the map by the transaction event handler. This works fine, but passing around the data in a global data structure just has an awful code smell. While another way would be to have the service layer read out the current revision and write the commit message itself etc. this smells just as bad IMHO with duplicated code and an unclear calling chain. So what I am looking for is a way to pass the data to the transaction as explained above, or maybe also something like: transaction.setAttribute(message, my commit message); tx.finish(); int revision = transaction.getAttribute(revision); Now I see my first snippet is quite specific to implementing a versioning system, but the later might be useful for other cases too. Is there any way to do this or is anything planned? Now that I've actually wrote about it my solution doesn't sound so bad really :) Best regards, Georg On 03.05.2010 17:03, Mattias Persson wrote: 2010/5/1 Georg M. Sorstgeorgso...@gmx.de mailto:georgso...@gmx.de Hi Mattias, hi list that's just what I've been looking for, congratulations on the amazing progress you are making on Neo4j! I am actually trying to use the TransactionEventHandler to implement automatic versioning similar to what was discussed a while ago. The beforeCommit() handler seems like a perfect fit and provides all the data I need. Still, I have one problem: in beforeCommit() I fetch and increment a revision number that's stored in a special node and use that number to build the current revision structure. This brings up a few questions: 1. How atomic are Neo4j commits? Will two concurrent commits interfere when getting and incrementing the revision number? Transactions are atomic, but if transaction T1 reads a value and modifies it, but before it modifies it T2 reads the same value in the intent to modify it, there's a possibility that T1 and T2 will read the same value. And if they both increment the value they both will set it to the same value (which would not be the intended behavior). What you would need to do is to make sure T1 has a write-lock on the node which carries this revision property, that way T2 will have to wait until T1 is committed and will read the correct value. There's no nice way
Re: [Neo] Event framework has landed
2010/5/1 Georg M. Sorst georgso...@gmx.de Hi Mattias, hi list that's just what I've been looking for, congratulations on the amazing progress you are making on Neo4j! I am actually trying to use the TransactionEventHandler to implement automatic versioning similar to what was discussed a while ago. The beforeCommit() handler seems like a perfect fit and provides all the data I need. Still, I have one problem: in beforeCommit() I fetch and increment a revision number that's stored in a special node and use that number to build the current revision structure. This brings up a few questions: 1. How atomic are Neo4j commits? Will two concurrent commits interfere when getting and incrementing the revision number? Transactions are atomic, but if transaction T1 reads a value and modifies it, but before it modifies it T2 reads the same value in the intent to modify it, there's a possibility that T1 and T2 will read the same value. And if they both increment the value they both will set it to the same value (which would not be the intended behavior). What you would need to do is to make sure T1 has a write-lock on the node which carries this revision property, that way T2 will have to wait until T1 is committed and will read the correct value. There's no nice way of locking a node other than setting/removing a property or creating/deleting relationships on it, so I'd say an ugly, but perfectly working way would be to do something like this: nodeWithRevision.removeProperty( a dummy property ); int counter = (Integer) nodeWithRevision.getProperty( revision ); so that neo4j is forced to take a write-lock on that node before getting the counter property. A nicer way will be exposed soon to do this instead! 2. How can I return the revision number from the TransactionEventHandler so I can use it in the caller (my service classes in this case)? I'd say it'd be better if the service classes could read the revision from the node which has the revision directly, that way you'd always get the committed value. Maybe your handler could have a getRevision() method which reads the revision property from that revision node. 3. The caller should be able to pass data to the transaction, for now just the commit message. Of course I can temporarily store this in a node or attach it to the thread etc. but that just seems wrong. How can I do this right? I don't know what you mean by pass data to the transaction if it would not be to store something in the graph, f.ex. a property on a node. What exactly do you mean by that? Thanks and best regards, Georg On 27.04.2010 10:15, Mattias Persson wrote: Hi everyone! I'm quite pleased to announce that the new event framework has been committed in kernel 1.1-SNAPSHOT. After feedback from you guys the framework got quite small and cosy. Here's a summary. *TransactionEventHandler* can be registered at a GraphDatabaseService and will thereafter recieve diffs of modifications made in each transaction before and after they are committed. The transaction can still be modified in beforeCommit() and that method can also throw an exception to prevent the transaction from committing, causing a TransactionFailureException to be thrown from the code which is committing the transaction. *KernelEventHandler* can be registered at a GraphDatabaseService and will receive notifications about when a shutdown is about to occur for the GraphhDatabaseService instance. It will also receive notifications about kernel panics which is a state which the kernel can come to from where it cannot continue without needing to be restarted. An example of such an error would be a hard drive breakdown or when no more space is left on the device the graph database is running on. The next step is to write an auto indexer for the IndexService so that that you won't have to do the manual indexService.index( node, key, value ) anymore. Another thing would be to remove (deprecate) the IndexService#shutdown() method as it no longer would be required. So it'd be great if you guys would try this out and tell us how it feels. -- Georg M. Sorst Dipl. Inf. (FH) http://vergiss-blackjack.de Ignaz-Harrer-Str. 13 / Top 19 5020 Salzburg Österreich Tel: +43 (0)650 / 53 47 200 -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] Event framework has landed
Hi Mattias, hi list that's just what I've been looking for, congratulations on the amazing progress you are making on Neo4j! I am actually trying to use the TransactionEventHandler to implement automatic versioning similar to what was discussed a while ago. The beforeCommit() handler seems like a perfect fit and provides all the data I need. Still, I have one problem: in beforeCommit() I fetch and increment a revision number that's stored in a special node and use that number to build the current revision structure. This brings up a few questions: 1. How atomic are Neo4j commits? Will two concurrent commits interfere when getting and incrementing the revision number? 2. How can I return the revision number from the TransactionEventHandler so I can use it in the caller (my service classes in this case)? 3. The caller should be able to pass data to the transaction, for now just the commit message. Of course I can temporarily store this in a node or attach it to the thread etc. but that just seems wrong. How can I do this right? Thanks and best regards, Georg On 27.04.2010 10:15, Mattias Persson wrote: Hi everyone! I'm quite pleased to announce that the new event framework has been committed in kernel 1.1-SNAPSHOT. After feedback from you guys the framework got quite small and cosy. Here's a summary. *TransactionEventHandler* can be registered at a GraphDatabaseService and will thereafter recieve diffs of modifications made in each transaction before and after they are committed. The transaction can still be modified in beforeCommit() and that method can also throw an exception to prevent the transaction from committing, causing a TransactionFailureException to be thrown from the code which is committing the transaction. *KernelEventHandler* can be registered at a GraphDatabaseService and will receive notifications about when a shutdown is about to occur for the GraphhDatabaseService instance. It will also receive notifications about kernel panics which is a state which the kernel can come to from where it cannot continue without needing to be restarted. An example of such an error would be a hard drive breakdown or when no more space is left on the device the graph database is running on. The next step is to write an auto indexer for the IndexService so that that you won't have to do the manual indexService.index( node, key, value ) anymore. Another thing would be to remove (deprecate) the IndexService#shutdown() method as it no longer would be required. So it'd be great if you guys would try this out and tell us how it feels. -- Georg M. Sorst Dipl. Inf. (FH) http://vergiss-blackjack.de Ignaz-Harrer-Str. 13 / Top 19 5020 Salzburg Österreich Tel: +43 (0)650 / 53 47 200 ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] Event framework has landed
Could you please supply code to reproduce this? 2010/4/29 Atle Prange atle.pra...@gmail.com Really nice, but it seems that afterCommit() never receives any data, the TransactionData argument is always null.. On Tue, Apr 27, 2010 at 10:15 AM, Mattias Persson matt...@neotechnology.com wrote: Hi everyone! I'm quite pleased to announce that the new event framework has been committed in kernel 1.1-SNAPSHOT. After feedback from you guys the framework got quite small and cosy. Here's a summary. *TransactionEventHandler* can be registered at a GraphDatabaseService and will thereafter recieve diffs of modifications made in each transaction before and after they are committed. The transaction can still be modified in beforeCommit() and that method can also throw an exception to prevent the transaction from committing, causing a TransactionFailureException to be thrown from the code which is committing the transaction. *KernelEventHandler* can be registered at a GraphDatabaseService and will receive notifications about when a shutdown is about to occur for the GraphhDatabaseService instance. It will also receive notifications about kernel panics which is a state which the kernel can come to from where it cannot continue without needing to be restarted. An example of such an error would be a hard drive breakdown or when no more space is left on the device the graph database is running on. The next step is to write an auto indexer for the IndexService so that that you won't have to do the manual indexService.index( node, key, value ) anymore. Another thing would be to remove (deprecate) the IndexService#shutdown() method as it no longer would be required. So it'd be great if you guys would try this out and tell us how it feels. -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] Event framework has landed
Oo, wait a minute... I saw the problem. Try again with the latest code (just committed)! 2010/4/29 Atle Prange atle.pra...@gmail.com Really nice, but it seems that afterCommit() never receives any data, the TransactionData argument is always null.. On Tue, Apr 27, 2010 at 10:15 AM, Mattias Persson matt...@neotechnology.com wrote: Hi everyone! I'm quite pleased to announce that the new event framework has been committed in kernel 1.1-SNAPSHOT. After feedback from you guys the framework got quite small and cosy. Here's a summary. *TransactionEventHandler* can be registered at a GraphDatabaseService and will thereafter recieve diffs of modifications made in each transaction before and after they are committed. The transaction can still be modified in beforeCommit() and that method can also throw an exception to prevent the transaction from committing, causing a TransactionFailureException to be thrown from the code which is committing the transaction. *KernelEventHandler* can be registered at a GraphDatabaseService and will receive notifications about when a shutdown is about to occur for the GraphhDatabaseService instance. It will also receive notifications about kernel panics which is a state which the kernel can come to from where it cannot continue without needing to be restarted. An example of such an error would be a hard drive breakdown or when no more space is left on the device the graph database is running on. The next step is to write an auto indexer for the IndexService so that that you won't have to do the manual indexService.index( node, key, value ) anymore. Another thing would be to remove (deprecate) the IndexService#shutdown() method as it no longer would be required. So it'd be great if you guys would try this out and tell us how it feels. -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] Event framework has landed
Fixed, nice :) atle On Thu, Apr 29, 2010 at 12:16 PM, Mattias Persson matt...@neotechnology.com wrote: Oo, wait a minute... I saw the problem. Try again with the latest code (just committed)! 2010/4/29 Atle Prange atle.pra...@gmail.com Really nice, but it seems that afterCommit() never receives any data, the TransactionData argument is always null.. On Tue, Apr 27, 2010 at 10:15 AM, Mattias Persson matt...@neotechnology.com wrote: Hi everyone! I'm quite pleased to announce that the new event framework has been committed in kernel 1.1-SNAPSHOT. After feedback from you guys the framework got quite small and cosy. Here's a summary. *TransactionEventHandler* can be registered at a GraphDatabaseService and will thereafter recieve diffs of modifications made in each transaction before and after they are committed. The transaction can still be modified in beforeCommit() and that method can also throw an exception to prevent the transaction from committing, causing a TransactionFailureException to be thrown from the code which is committing the transaction. *KernelEventHandler* can be registered at a GraphDatabaseService and will receive notifications about when a shutdown is about to occur for the GraphhDatabaseService instance. It will also receive notifications about kernel panics which is a state which the kernel can come to from where it cannot continue without needing to be restarted. An example of such an error would be a hard drive breakdown or when no more space is left on the device the graph database is running on. The next step is to write an auto indexer for the IndexService so that that you won't have to do the manual indexService.index( node, key, value ) anymore. Another thing would be to remove (deprecate) the IndexService#shutdown() method as it no longer would be required. So it'd be great if you guys would try this out and tell us how it feels. -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] Event framework has landed
On Thu, Apr 29, 2010 at 2:19 PM, Atle Prange atle.pra...@gmail.com wrote: BTW.: I wrote a new IndexService using BabuDB [1]. BabuDB is really fast, but does not work for fulltext query. For now the IndexService is embedded in the Object-graph mapper i wrote [2]. Anyone is free to check it out, if it looks interesting it could be moved to a neo4j subproject. Nice. Does BaduDB expose an XAResource? that would make it a whole lot easier to integrate with the transaction system of Neo4j. -- Tobias Ivarsson tobias.ivars...@neotechnology.com Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] Event framework has landed
No, its just an index/key-value store with no transactional capabilities other than when no exception is being thrown, the index is updated. Any tx handling must be impemented on top. On Thu, Apr 29, 2010 at 2:35 PM, Tobias Ivarsson tobias.ivars...@neotechnology.com wrote: On Thu, Apr 29, 2010 at 2:19 PM, Atle Prange atle.pra...@gmail.com wrote: BTW.: I wrote a new IndexService using BabuDB [1]. BabuDB is really fast, but does not work for fulltext query. For now the IndexService is embedded in the Object-graph mapper i wrote [2]. Anyone is free to check it out, if it looks interesting it could be moved to a neo4j subproject. Nice. Does BaduDB expose an XAResource? that would make it a whole lot easier to integrate with the transaction system of Neo4j. -- Tobias Ivarsson tobias.ivars...@neotechnology.com Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
