debugging script needed

[HeSe]

I tried to register a GemServer and start it for debugging purposes via a script based on: Gemserver instance scriptStartServiceOn:

Unfortunatly the implementation and usage of doTransaction: ends up in a never commited transaction on the server side. Therefore a change in the TestingGemSession won't be recognized in the GemServerDebugging session.

I am not so sure if the current implementation of doTransaction should rather abort an existing transaction on the ZincServer side and always create a new one.....

[dalehenrich]

@HeSe are you trying to run the "debugging script" in an interactive session? If so the scriptStartServiceOn: is definitely not something you want to do in an interactive session as it goes into manualTransaction mode which is intended to b used only by servers ...

If you are in an interactive session, try using startServerOn: ... it will not return, but that behavior is necessary to run a server in an "interactive" session .. you should also set debugMode to true (for zinc) so that the exceptions are passed to the interactive session ... I assume that you are NOT using seaside ...

using continuations and debugging against a remote gem server is not a bad way to debug things, depending upon what you are trying to do ....

The missing documentation that I referred to in my GLASS email are intended to go into more detail about production and debugging ...

[HeSe]

Hmmm,... I feel like using startServerOn: with the current implementation of doTransaction: in GRGemStonePlatform results in a Transaction never commited and therefor all Unitests that try to test the storage of data via REST requests based on ZincREST will fail since the data change is never commited since the "System inTransaction" check always returns true.

[dalehenrich]

Interestingly enough my current work (started over the weekend) with Issue #10 is to work on cleaning up the transaction sematics for GemServer .... So far almost all of the servers have been aimed at Seaside, which has built-in transaction semantics ... so the gem servers haven't been set up to the heavy lifting ... with Issue #10 I intend to at least create some test applications for rest and non-seaside http servers that have some transaction support ... I've built a GemServerTestServer class that uses commited state to initiate jobs, but I'm using it to work through different transaction scenarios

You mention that System inTransaction always answers true ... the gemservers should be running in manual transaction mode so if System inTransaction is true, someone has started a transaction ... Frankly this is exactly the area I want to explore with Issue #10 so perhaps we could meet on gitter to chat a bit?

[dalehenrich]

@HeSe for a gem server you really should be running in manual transaction mode .... part of the setup in GemServer>>scriptStartServiceOn: ... I've commented on gitter as well ...

[HeSe]

I don't. I changed the script to a pure startServerOn:. Like you mentioned Zinc is not having this inTRansactionDo: functionality like Seaside does. I took the transaction handling of Seaside and added it to my Zinc port. When I start a ZincServer with Jade or Gemtools remotely then this interactivesession is blocked and it is also in a transaction then. You need to have a commit otherwise the Unittests won't realize/be able to test that the data has been changed during the REST call. This isn't an issue once you have the Unittests run from a different client, but if the Test-Client and the Test-Server are one and the same GemstoneDB,... you need a proper/manual handling of the transactions once the client instance sends REST calls to the server instance.

[dalehenrich]

@HeSe I think I've addressed the debugging issue and here' the relevant documentation