Re: Cayenne callback listener in single transaction
Hi Artem,
> In fact I am interested in second scenario.
>
> 1. open transaction
> 2. perform main sql INSERT (db assign PK for new record)
> 3. perform callback operation (newly generated PK is accessible )
> 4. close transaction
Sure. Here is how to do it with CommitLogModule:
ServerRuntime.builder()
.addModule(CommitLogModule.extend().addListener(MyCommitLogListener.class).module())
public class MyCommitLogListener implements CommitLogListener {
public void onPostCommit(ObjectContext originatingContext, ChangeMap
changes) {
// Here put the code for step #3.
// ChangeMap should have all the info on changed objects...
}
}
> On Dec 27, 2019, at 12:23 PM, Artem Kravchenko
> wrote:
>
> Hello Andrus
> Thanks for your replay.
>
> Not sure how it works butfor example:
> I need to insert some Entity and on @PostPersist get the PK of this record.
> So the question is:
>
> will 'insertBefore' collect all changes (main commit and callback) first and
> then apply bulk SQL (inserts/updates)
>
> or
>
> 1. open transaction
> 2. perform main sql INSERT (db assign PK for new record)
> 3. perform callback operation (newly generated PK is accessible )
> 4. close transaction
>
> In fact I am interested in second scenario
> first one doesn't fit for us
>
Re: Cayenne callback listener in single transaction
Hello Andrus Thanks for your replay. Not sure how it works butfor example: I need to insert some Entity and on @PostPersist get the PK of this record. So the question is: will 'insertBefore' collect all changes (main commit and callback) first and then apply bulk SQL (inserts/updates) or 1. open transaction 2. perform main sql INSERT (db assign PK for new record) 3. perform callback operation (newly generated PK is accessible ) 4. close transaction In fact I am interested in second scenario first one doesn't fit for us
Re: Cayenne callback listener in single transaction
On 19/12/19 1:18am, Artem Kravchenko wrote: So the problem which I faced with: the commits (main one and subsequent from listener) are two different jdbs transaction, which is reasonable in fact. But in such case the data consistency is not guaranteed - second commit might be failed. It is really important for me. At first glance, I cannot understand why wrapping them in a single transaction would not be the default behaviour here. Adding records in @PostPersist is likely something like: * audit records to track changes * financial transactional data (eg writing to a general ledger when invoice is created) * updating denormalised data (eg. contact.owing) which might be done for search or performance reasons. In each case I can think of, rolling back the whole transaction would be a more appropriate behaviour in case of failure. Cheers Ari
