TxNumber not set in memory after commit

[Damián]

Hi,

Apparently fields of type TxNumber are properly set in persistent
storage but not in memory. Here's a use case:

doInTxn {
val x = new ObjectWithTxNumberField
println(x.getTxNumber)
}

The output of this snippet is 0, but if you look into MySQL the
txNumber is set to a proper value.

Any thoughts?


Damián

[Joao Cachopo]

Damián <damian....@gmail.com> writes:

Yes, that is correct.

You should not access the value of the TxNumber slot before it is saved
because it is not possible to know its value before the transaction is
actually committed.

I think I mentioned this before...

An alternative would be to throw an exception when you tried to access
this value, but it complicates the code because I would have to
distinguish between a value having been written (and read) before or
not.

As the purpose of the TxNumber value-type is very specific, I think that
the current behavior is acceptable.

Is there any good reason why you need to access its value before the
object containing it is committed?

Best regards,
--
João Cachopo

[Damián Arregui]

Joao Cachopo wrote:
> I think I mentioned this before...

I'm sorry, you did mention this indeed. The use case causing the problem
is the following:

val x = doInTxn {
new ObjectWithTxNumberField
}

doInTxn {
println(x.getTxNumber)
}

So, even if I try to access the tx number from a different transaction
it is not properly set. Apparently the in-memory cache is not being updated.

Damián

[Joao Cachopo]

Damián Arregui <damian....@gmail.com> writes:

> The use case causing the problem is the following:
>
> val x = doInTxn {
> new ObjectWithTxNumberField
> }
>
> doInTxn {
> println(x.getTxNumber)
> }
>
> So, even if I try to access the tx number from a different transaction
> it is not properly set. Apparently the in-memory cache is not being
> updated.

This one took me a little longer to fix, not because the fix was that
hard but because I had to figure it out how best to solve it.

I hesitated between keeping the current programmers interface or not. I
don't like to change things in an incompatible way, but keeping the same
programmers interface in this case would make things much more awkward
in the internals of the fenix-framework.

So, I finally decided to go for a solution that will force you to change
your code. I apologize, but I hope that the changes are minimal.

I've committed a change to the fenix-framework that changes the behavior
of the TxNumber value-type.

Whereas before when you had in the DML something like this:

class MyClass {
TxNumber num;
}

the code generated for the _Base class was along these lines:

class MyClass_Base ... {
public long getNum();
}

now it is

class MyClass_Base ... {
public TxNumber getNum();
}

that is, the TxNumber value-type in the DML is no longer an alias for
the long primitive type in Java.

So, to access the long value, instead of "myObj.getNum()" you have to
use now "myObj.getNum().getNumber()".

Moreover, you have to initialize the slot with an instance of the
TxNumber class if you want it to be written to the database:

class MyClass extends MyClass_Base {
public MyClass() {
setNum(new TxNumber());
}
}

Note that, in general, it doesn't make much sense to call setNum(...)
later to change the instance of TxNumber of a given object.

Also, with this version, calling the TxNumber.getNumber() value in a
transaction for an instance of TxNumber that was never written before
will result in an IllegalStateException.

Likewise, you will have the same exception thrown if you compare an
instance of TxNumber with another (using equals) if any of these
instances was not written before.

Finally, the fullname of the TxNumber class is
pt.ist.fenixframework.TxNumber.

I think that I mentioned all of the important things but feel free to
ask/comment.