jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guo Du <mrdu...@gmail.com>
Subject Re: [jr3] Synchronized sessions
Date Sat, 27 Feb 2010 10:12:53 GMT
On Sat, Feb 27, 2010 at 8:47 AM, Thomas Müller <thomas.mueller@day.com> wrote:
> "consistency". I don't know of a relational database that allows you
> to violate referential integrity, unique key constraints, or check
> constraints - simply by using the same connection in multiple threads.
jdbc server response for constraints check and will throw exception at the end.

jcr repository should have some point to do the constraints check as
well. Should fail the operation if conflict found.


> Jackrabbit did and does have such problems (nodes that point to
> non-existing parent nodes; nodes that point to non-existing child
> nodes). *Those* are the problems I want to solve.


> It should never be necessary to run a "consistency check" or
> "consistency fix". It should never be necessary to delete nodes
> because they are "corrupt". Nodes should never get corrupt.
Agree, it doesn't matter what developer do via jcr api, data should
never be corrupted in repository.

>> But not with synchronizing all methods.
> As I already wrote, if this does turn out to be a performance problem,
> we can remove synchronization where required.
Performance is not major concern, it's the design. Synchronisation
should be limited and should be applied to low level where necessary,
instead blindly on session for everything. . Sync on session level
could increase the deadlock as well.

Your response could well applied to the sync everything on seesion:)
Unfortunately, it's not that simple to find out whose program caused
the problem. Usually other people have to fix the problem than those
who caused them.

-Guo

Mime
View raw message