Cayenne PK generator caches blocks of 20 keys for each entity by default to
reduce the number of DB trips for such trivial
things as PKs.
> We think this is a bug because on the PK generation phase on cayenne no data,
> always, should be ever retrieved from the cache, which would lead to repeated
> primary keys...
No this is not a bug, however the trick is that the underlying sequence should
be configured to increment by 20, which is the case if the sequence was
generated from the Modeler. (This is a general rule if of course, so if you'd
change the key cache to any value from 1 to infinity, the sequences should be
updated accordingly).
> @Override
> public void commitChanges() throws CayenneRuntimeException {
> super.commitChanges();
> getQueryCache().clear();
> }
>
> @Override
> public void commitChangesToParent() {
> super.commitChangesToParent();
> getQueryCache().clear();
> }
The above won't have any effect on PK caching. However you can configure
desired sequence cache in the Modeler:
http://people.apache.org/~aadamchik/sequence.png
Andrus
On Jun 16, 2011, at 6:36 PM, Bruno René Santos wrote:
> Hello all,
>
> We had a problem on one of our applications on Oracle because, we think, of
> the cayenne cache and we wanted to have some sort of confirmation if we are
> seeing this correctly...
>
> On Oracle, in order to get the next PK we need to execute the query:
>
> Select sequence_name.next_val from DUAL
>
> Sometimes the query logger did not print this command before an INSERT. After
> some testing we reached to the conclusion that this was a cache issue and so
> we overrode CommitChanges and CommitChangesToParent in order to clear the
> query cache after the commit phase, like this:
>
> @Override
> public void commitChanges() throws CayenneRuntimeException {
> super.commitChanges();
> getQueryCache().clear();
> }
>
> @Override
> public void commitChangesToParent() {
> super.commitChangesToParent();
> getQueryCache().clear();
> }
>
> We think this is a bug because on the PK generation phase on cayenne no data,
> always, should be ever retrieved from the cache, which would lead to repeated
> primary keys...
>
> Can this be true?
>
> Thanx
> Bruno
> --
> Bruno René Santos | [email protected] <mailto:[email protected]> | Gestor
> de Projectos | Analista | Programador | Investigador
>
> Holos - Soluções Avançadas em Tecnologias de Informação S.A.
> Parque de Ciência e Tecnologia de Almada/Setúbal . Edifício Madan Parque
> Rua dos Inventores . Quinta da Torre . 2825 - 182 Caparica . Portugal
> Phone: +351 210 438 686 . Fax: +351 210 438 687 . Web: www.holos.pt
>
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed. If
> you are not the intended recipient or the person responsible for delivering
> the email to the intended recipient, be advised that you have received this
> email in error and that any use, dissemination, forwarding, printing, or
> copying of this email is strictly prohibited. If you have received this email
> in error please notify Bruno René Santos by telephone on +351 210 438 686
>
