[Glass] General questions about how to develop ...

[James Foster]

Hi Martin,

While Otto has given good answers, I’ll add my perspective as well.

On Nov 19, 2013, at 8:56 AM, itlists at schrievkrom.de wrote:

> ... when I am developing applications with jade/Gemstone etc I have some
> problems understanding how to make it "right":
> 
> The environment: GS running under Linux in a VirtualBox, Jade on the
> same machine.

Sounds right! ;-)

> -> When starting, the development is done with Jade and the user
> DataCurator.

That would be my choice! ;-)

> -> Now I would like to run the end-user application. Should one create
> another db user to run the end user application ?

I think Otto addressed nicely the issue of running a production system on a separate machine from the development system. My first reading of your question was that you are dealing more with just running your application as part of the development process. In any case, if you are writing a web application then you probably want to use the same user for both development and runtime. Otherwise, you need to make the domain classes visible to the other user, and that is a bit of work (though it can be done).

> -> this end-user application is running in its own gem, right ? Must I
> use Topaz and several filein (in a batch) to import the sources and then
> start the application from within Topaz ?

If you are using the same user, then there is no need to file in the code again.

Typically, the application would run in a separate Gem, but this is primarily so that you don’t block your development effort. (Recall that the web server and application will only run if you have handed control over to the Gem by executing a long-running sleep in the primary thread.) If you want to do it all in one Gem, then do some development, commit, start the web server (and let the development UI block), test the application, click the ‘Break’ button on the Jade window that shows while the UI is blocked to stop the server, then do some more development.

Alternatively, you can use Topaz (and DataCurator) to run your application. You can even start another Jade process and run the application from that second process (if you want to stay in Jade and away from Topaz). That way if an error does occur (and is not caught by the application), then you can debug it in Jade!

> -> Can I develop further on (in parallel) with Jade and DataCurator ?

Yes, as long as you have two sessions (either two Jade processes or Jade and Topaz).

> -> can I update the running end-user-application while it is running to
> get new method versions - or do I have to stop that gem and restart it
> again  ?

No need to stop the application as long as you handle the transactions properly. If the application does an abort/commit for each user action (typically a web page request/response), then any changes you make and commit will be visible to your application when it next does an abort or commit. As you describe below, the typical model for the application server is to wait on a socket for a request, when a request is received, read the request, abort (to get the latest data and code), take action on the request, and commit the response. If you then do an abort or commit in Jade, you will immediately see any data changes made by your application, which can be handy.

> When developing server applications - which I really would like to do,
> if I could at least file in all needed sources do I understand it correctly:

Again, if you are just running the application as part of your development process, there is no need for a separate user and code management.

> - that within a gem only ONE request at a time can be handled (also due
> to global transaction management)

Yes, exactly. While you could handle multiple requests at a time, the VM would only run one process/thread at a time (as in Pharo, VA, VW) and intermediate work would be shared (and lost if anyone did an abort). So it isn’t so much a limitation that you can’t use #’fork’ but if you did you would be sharing the data (as you would in Pharo, VA, VW) and would lose the transaction isolation feature of GemStone.

>  - that means: wait for request, abort transaction, do request work,
> abort or commit changes, wait for request  etc …

Yes, this is the application server loop. You can just leave it running and make your changes in another session. Each time you commit, your new code is immediately used.

The only time you need to stop and restart the application server is if you change the class schema of the application server. That is, if you add an instance variable to something referenced from the long-running app server gem, then that object would not get migrated so you would still be using the old object. So occasionally I find myself wondering why a changed method isn’t being executed and I find that I’m running code in an old version of a class.

> Marten Feldtmann

Does that help?

James