Fork me on GitHub
#datomic
<
2016-04-19
>
casperc09:04:24

I have a question regarding transaction functions and which guarantees the database that is passed provides. Can I always be certain that the db value is “sync’ed”, meaning that it holds all the previously transacted values?

pesterhazy09:04:16

@casperc: what do you mean?

casperc09:04:30

@pesterhazy: Can you expand on which part is unclear? I am trying to find out if the db value in a transactor function is always up to date or can be lagging behind (like in a peer, unless you sync it)

pesterhazy09:04:52

ah now I get you

pesterhazy09:04:11

didn't know that peers needed to sync actually, so maybe I'm not in the best position to answer this

pesterhazy09:04:46

but: it would be very surprising if the db wasn't guaranteed to be up to date, because otherwise the transactor wouldn't be able to ensure consistency

casperc09:04:25

I ask because I have a database function which runs during an import, which obviously puts a fair amount of pressure on the transactor, and it doesn’t seem like the db value is up to date. Sometimes I will get an “java.lang.IllegalArgumentException: :db.error/not-an-entity Unable to resolve entity” for a lookup which has already been passed to the transactor. Retrying the transaction later will succeed.

casperc09:04:32

@pesterhazy: I agree, which is why i find it surprising. I might be making some error in my import, but it would be nice to know the guarantees that are provided.

casperc09:04:51

I’ll leave it here for when @bkamphaus wakes up

Lambda/Sierra13:04:58

Transactions execute serially. A transaction function, when called as part of a transaction, always has the most recent value of the database.

Ben Kamphaus13:04:28

@casperc — Re: "for a lookup which has already been passed to the transactor.” — and in that case the transaction has definitely succeeded (e.g. no retry) and for a t prior to the dependent transactions arrival? If you’re loading a transactor with a bulk async import from the peer, I would suspect the order transactions are being submitted on the peer may be behind this.

casperc13:04:48

@bkamphaus: So just to be clear, the db value passed to a transaction function should be up to date e.g. it cannot lag behind as is possible with a peer?

Ben Kamphaus13:04:48

@casperc: yes, it’s guaranteed to be the most recent db value at the time the transaction arrives at the transactor. (as @stuartsierra mentions, guaranteed by the transactor serializing all transactions, which is inclusive of transaction function calls).

casperc13:04:27

Ah, sorry I missed stuarts response.

Lambda/Sierra13:04:54

@casperc If you are running an import job with many transactions, it may be the case that the transactions are not arriving at the Transactor in the order you expect.

casperc13:04:21

Yeah, that sounds to be the case simple_smile

casperc13:04:23

My problem is that several 100k transactions have not completed at the point i thought they were, but clearly the problem is on my end then.