Hi Robert, I have posted this same question on Adobe's Help Forums too.
Here's one of my comments there that I am cross posting here in case that
can clarify my expectations and what is actually happening:

There are at least two scenarios:

*Scenario 1*: The item 297e1b7d-8064-404f-b765-27ba71dff64a is deleted
before the query executed. In this case it should not appear in the search
returned by query.execute() at all. Hence this exception should not be
thrown in this scenario.

*Scenario 2*: While the query.execute() is in progress, the item
297e1b7d-8064-404f-b765-27ba71dff64a is deleted from the repository by
another thread. In this case Jackrabbit should be smart enough to handle
this situation, rather than failing by throwing an exception.

Scenario 1 is obvious I think.

If you compare Scenario 2 to JDBC, this is what happening:

Let's pretend we have a table called PAGE_CONTENT. Multiple threads read,
write, or modify rows in this thread. In one thread, we execute the
following code:


   1.     final Connection conn = ...;
      2.     final PreparedStatement stmt =
conn.prepareStatement("SELECT * FROM PAGE_CONTENT WHERE ... AND
HOST_NAME IS NOT NULL")
      3.     final ResultSet results = stmt.executeQuery();

Even when the ISOLATION LEVEL is set to READ COMMITTED, JDBC will never
ever throw an exception here if while stmt.executeQuery() is in progress,
another thread deletes a few rows from the table.

But here in JCR, this is what we are exactly seeing. This is not acceptable
IMHO. If it is, I am looking for a clear explanation as to why this makes
sense.


Best regards,
Behrang
http://www.behrang.org

On Wed, Dec 3, 2014 at 9:57 AM, Behrang Saeedzadeh <behran...@gmail.com>
wrote:

> Hi Robert
>
> That was a typo. I usually modify our code a bit before posting it online
> to avoid exposing actual property names, etc. Or sometimes just to get rid
> of unrelated cruft surrounding the subject. But I still can't convince
> myself that this bug makes sense. Looks like the isolation level
> implemented does not support repeatable reads properly.
>
> On Wed, 3 Dec 2014 at 8:26 am Robert Munteanu <romb...@apache.org> wrote:
>
>> Hi,
>>
>> On Tue, Dec 2, 2014 at 7:17 AM, Behrang Saeedzadeh <behran...@gmail.com>
>> wrote:
>> >     final Query query = queryManager.createQuery("", Query.JCR_SQL2);
>>
>> Is this the actual query invocation? You probably want something like
>>
>>     final Query query = queryManager.createQuery(statement,
>> Query.JCR_SQL2);
>>
>> Robert
>>
>

Reply via email to