search

GsDevKit / gsApplicationTools

This repository includes scripts and code that allow a more convenient setup of a Gemstone server application
MIT License
2 stars 2 forks source link

transaction semantics needs some work for snapping off continuations #10

Closed dalehenrich closed 9 years ago

dalehenrich commented 9 years ago

When an error occurs and we snap off a continuation for the object log, we need to make sure that we do a commit without interfering with the server's transaction semantics ... to complicate things a bit more, when we pass a non-resumable exception we might want to do a commit no matter what ... it's possible that we can depend upon the commit that we perform when the gem server exits?

dalehenrich commented 9 years ago

One more complication ... we want to make sure that all errors are unconditionally logged to the gem log ... oh and it is worth looking at the seaside error handling/logging code for inspiration as the application code may need to decide whether or not a commit is needed ...

dalehenrich commented 9 years ago

The real issue with transactions is that we may not want to persist the state that exists at the time of the error .....if the error is not resumable we will have to terminate the thread that is currently executing ... at a minimum ....

Now I think that we need to differentiate between application errors and server errors ... the application errors can decide what action should be taken: snap off continuation and continue (if possible), with or without a commit (with or without a preceding abort) ... perhaps the application should decide about whether or not the exception should be resumed ....

Errors should be handled completely differently than resumable exceptions (Break, Breakpoint or Halt)....We want the error continuation to be committed unless the commit would persist unwanted state ....

dalehenrich commented 9 years ago

released v1.0.0