For my use case I would have to be able to roll back the memory structure's changes when DB >transaction is aborted. It would be great if your new triggers functionality allow hooking up inYes, the new trigger functionality will have entry points for transaction aborts and commits as well as data operations.
transactional fashion e.g. on modification of the entry in db, on commit of
his modification and on abort of this modification. It would be also great if there were
3 types of triggers: on create entry, on update, >on delete.
Looking forward to see the triggers functionality. Can't you give any indication when it might beI'm afraid that we are prohibited from announcing release plans in advance. However, we'd like to make sure our test suite covers the kind of usage you describe.
available e.g. maybe this year?
-I am also planning on testing it out in a distributed environment, with a single JE master and a backup node(s), although only the master would be publishing the updates to ES.If I understand correctly, you will not be publishing based on updates to a JE replica node. Therefore, you don't need a trigger capability to do this. Triggers are needed on replicas to do this sort of thing, because it is JE that is doing the writes on the replica. On a JE master node (or a JE standalone node), it is the application that invokes the writes, and therefore the application can fairly easily publish the information to other entities as well.
To be honest, I am very new to BDB/JE, so I may be missing the context here.This forum thread is discussing triggers as a possible future feature.
The trigger functionality is present in the code, the documentation is in the class headers, no @Deprecated warnings or anything.The same is true of many internal methods in JE, but you really shouldn't use them. Please only use the methods in the javadoc.
Triggers is just a simple callback mechanism, which I thought suited my situation quite well - if it's going away, I'll try something else. All I expect from JE is that it allows me to conveniently access the data that has been committed within a transaction, triggers or aspects or whatever else is available. Any other suggestions?To access the data that has been committed, you'll need to query it using the Database and Cursor APIs, or the DPL (persist package) if you prefer. Triggers are not currently available.