You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Pontus Amberg <po...@milso.se> on 2011/12/23 16:45:29 UTC

Querying recently created data returns empty result

Hi!

I have some code in EJB:s where data is imported from a legacy system 
into a JCA instance of Jackrabbit. There's multiple methods in the EJB 
that perform small parts of the import and most methods are using a 
transaction of their own. Since this is EJB 3 stuff the transactions are 
controlled with annotations on the methods.

Most of the stuff seems to work fine but some methods try to query data 
imported by other methods using for example:

select * from [nt:unstructured] as n where n.type='abc' and n.id='123456'

and they return an empty result even if the methods importing the data 
seems to have succeeded. Is this normal behavior since the Lucene index 
needs some time to be updated or might there be somthing wrong with our 
code (transaction or session handling)?

/Pontus



Re: Querying recently created data returns empty result

Posted by Pontus Amberg <po...@comhem.se>.
I think I've found the problem. It seems to be the transaction handling
that is the causing the problems. The initial method where annotated with
@TransactionAttribute(TransactionAttributeType.REQUIRED) and
the methods that was invoked by the initial methods where annotated
with
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)

Changing the initial method to
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) seems
to fix the search problem since the transactions in the "REQUIRES_NEW"
methods are now commited when they are finnished.

/Pontus

On 2011-12-24 01:20, Pontus Amberg wrote:
> The nodes we are searching for does not contain binary data and I've 
> tried
> many different combinations of session saves and transactions commit and
> so far the query still fails. I'll take a closer look at it during the 
> weekend and
> see if I can find a solution.
>
> /Pontus
>
> On 2011-12-23T23:25:18 CET, Alexander Klimetschek wrote:
>> On 23.12.11 16:45, "Pontus Amberg"<po...@milso.se>  wrote:
>>> I have some code in EJB:s where data is imported from a legacy system
>>> into a JCA instance of Jackrabbit. There's multiple methods in the EJB
>>> that perform small parts of the import and most methods are using a
>>> transaction of their own. Since this is EJB 3 stuff the transactions 
>>> are
>>> controlled with annotations on the methods.
>>>
>>> Most of the stuff seems to work fine but some methods try to query data
>>> imported by other methods using for example:
>>>
>>> select * from [nt:unstructured] as n where n.type='abc' and 
>>> n.id='123456'
>>>
>>> and they return an empty result even if the methods importing the data
>>> seems to have succeeded. Is this normal behavior since the Lucene index
>>> needs some time to be updated or might there be somthing wrong with our
>>> code (transaction or session handling)?
>>
>> The search index should be updated once the JCR session is saved 
>> (that is
>> per spec - only full text indexing of binary data might get updated 
>> with a
>> delay). When using transactions, the actual persistence is moved from 
>> the
>> session save to the transaction commit, and I think that holds true for
>> the search index update as well.
>>
>> Cheers,
>> Alex
>>
>
>
>


Re: Querying recently created data returns empty result

Posted by Pontus Amberg <po...@comhem.se>.
The nodes we are searching for does not contain binary data and I've 
tried
many different combinations of session saves and transactions commit and
so far the query still fails. I'll take a closer look at it during the 
weekend and
see if I can find a solution.

/Pontus

On 2011-12-23T23:25:18 CET, Alexander Klimetschek wrote:
> On 23.12.11 16:45, "Pontus Amberg"<po...@milso.se>  wrote:
>> I have some code in EJB:s where data is imported from a legacy system
>> into a JCA instance of Jackrabbit. There's multiple methods in the EJB
>> that perform small parts of the import and most methods are using a
>> transaction of their own. Since this is EJB 3 stuff the transactions are
>> controlled with annotations on the methods.
>>
>> Most of the stuff seems to work fine but some methods try to query data
>> imported by other methods using for example:
>>
>> select * from [nt:unstructured] as n where n.type='abc' and n.id='123456'
>>
>> and they return an empty result even if the methods importing the data
>> seems to have succeeded. Is this normal behavior since the Lucene index
>> needs some time to be updated or might there be somthing wrong with our
>> code (transaction or session handling)?
>
> The search index should be updated once the JCR session is saved (that is
> per spec - only full text indexing of binary data might get updated with a
> delay). When using transactions, the actual persistence is moved from the
> session save to the transaction commit, and I think that holds true for
> the search index update as well.
>
> Cheers,
> Alex
>



Re: Querying recently created data returns empty result

Posted by Alexander Klimetschek <ak...@adobe.com>.
On 23.12.11 16:45, "Pontus Amberg" <po...@milso.se> wrote:
>I have some code in EJB:s where data is imported from a legacy system
>into a JCA instance of Jackrabbit. There's multiple methods in the EJB
>that perform small parts of the import and most methods are using a
>transaction of their own. Since this is EJB 3 stuff the transactions are
>controlled with annotations on the methods.
>
>Most of the stuff seems to work fine but some methods try to query data
>imported by other methods using for example:
>
>select * from [nt:unstructured] as n where n.type='abc' and n.id='123456'
>
>and they return an empty result even if the methods importing the data
>seems to have succeeded. Is this normal behavior since the Lucene index
>needs some time to be updated or might there be somthing wrong with our
>code (transaction or session handling)?

The search index should be updated once the JCR session is saved (that is
per spec - only full text indexing of binary data might get updated with a
delay). When using transactions, the actual persistence is moved from the
session save to the transaction commit, and I think that holds true for
the search index update as well.

Cheers,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel