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"<[email protected]> 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
