I thought that might be the answer, due to the fact that Lucene is not
transactional.
Thanks Marcel.
Yoav
Marcel Reutegger wrote:
>
> Hi,
>
> this is actually the intended behaviour, and the way it is specified in
> JSR 170.
> JSR 283 will relaxes the rules when changes are reflected in a query. it
> will
> basically be up to the implementation whether even transient changes are
> reflected in a query.
>
> regards
> marcel
>
> Yoav Landman wrote:
>> Hi,
>>
>> I am using Jackrabbit 1.4.5 with SpringModules 0.9. Before using
>> transactions, I was able to save() and search for the changes immediately
>> after saving.
>> With transactions, however, I can see my changes after save() by using
>> node
>> APIs, but it is only after I commit the transaction that I can get the
>> changed nodes to show up in search results.
>> This is the logic:
>>
>> utx1.begin()
>> nodeA.addNode("b");
>> nodeA.save();
>> nodeA.get("b"); //works
>> queryManager search for b; //does not work (zero results)
>> utx1.commit();
>> utx2.begin();
>> queryManager search for b; //works (single result)
>> //Do some stuff
>> utx2.commit();
>>
>>
>> I was under the impression that save() makes the transaction's transient
>> changes visible to subsequent search operations within the same
>> transaction.
>> At least, this is how it works without transactions, so I do not
>> understand
>> why introducong transactions changes this behavior. This leads to having
>> to
>> use an artificial logic by making changes in separate tx, just to be able
>> to
>> search the results immediately thereafter (which also breaks atomicity).
>>
>> Am I missing something? Is this a likely bug or the intended behavior?
>>
>> Thanks,
>>
>> Yoav
>>
>>
>
>
>
--
View this message in context:
http://www.nabble.com/Cannot-search-for-saved-uncommitted-changes-tp18400948p18439821.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
