Cannot search for saved uncommitted changes

[Yoav Landman]

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

[Marcel Reutegger]

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
>
>

[Yoav Landman]

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
>
>