Neo4j模拟SERIALIZABLE隔离级别：锁释放用SET false还是REMOVE？

Great question—simulating serializable isolation with manual lock properties in Neo4j requires consistency and clarity to avoid edge cases. Let’s break down your two options and which one makes sense:

Option 1: SET n._lock_ = false #

This approach keeps the _lock_ property on the node but toggles its value to indicate the lock is released.

• Pros: You don’t have to handle "property doesn’t exist" checks in subsequent lock verification logic. If your code expects the _lock_ property to always be present, this avoids null-related errors.
• Cons: Leaves a permanent (and unnecessary) property on the node, which adds tiny overhead to storage and query performance over time. If you’re working with a large dataset, these redundant properties can add up.

Option 2: REMOVE n._lock_ #

This completely removes the lock property from the node, returning it to its original state.

• Pros: Cleans up the node entirely—no leftover metadata cluttering your graph. This is cleaner for long-term graph health, especially if locks are short-lived.
• Cons: Requires adjusting your lock-checking logic to first verify the property exists. For example, instead of just checking n._lock_ = true, you’d need to write exists(n._lock_) AND n._lock_ = true to avoid false negatives from null values.

Which Should You Choose? #

The right choice depends on your consistency rules:

• If you want to keep your lock-checking logic simple (no existence checks), go with SET n._lock_ = false. Just be aware of the minor storage overhead.
• If you prioritize a clean graph state and don’t mind adjusting your check logic, REMOVE n._lock_ is the more elegant approach.

Critical Notes to Avoid Issues #

• Always perform lock acquisition and release within the same transaction. If you split these operations across transactions, you risk race conditions where another process grabs the lock before yours is released.
• When simulating serializable isolation, make sure all processes follow the same lock protocol (e.g., always check for the lock before modifying the node). Inconsistent logic can lead to deadlocks or dirty reads.
• Remember that Neo4j’s default isolation level is READ COMMITTED—manual locks are a workaround, and you should test your implementation thoroughly to ensure it actually enforces serializable behavior for your use case.

内容的提问来源于stack exchange，提问作者alexanoid