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

... 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.

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

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

-> 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 ?

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

-> 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  ?

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:

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

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

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

... 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.

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

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

-> 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 ?

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

-> 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  ?

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:

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

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



Marten Feldtmann

(not very polite to post without my name - sorry for that)


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Marten.

your list of questions is excellent. I have no answers for you, because
I am wondering about the same things.

Joachim

Am 19.11.13 07:53, schrieb [hidden email]:

--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

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

Consider developing in Pharo and deploying in GS. If you want to use
refactoring tools and get speed.

There are some discussions in this mailing list on the topic. And
there are some compatibility packages that make it easier.

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

Most definitely. You should have a separate VM with its own setup and
upgrade that once your developed software is well tested.

> -> 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 ?

In principle, yes. The end user application runs its own stone and
possibly load balanced gems. These gems are topaz sessions started up
by scripts in <your GS installation>/seaside/bin.

You can use Metacello / Monticello to load the source. So you save it
from your development environment in a Monticello repository and then
get it across to your end user application. On that system you use
Metacello to load it in again.

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

You can do that. But surely you may break the application while you
are working if your end user is on it at the same time?

> -> 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  ?

It is possible to update while it is running. But it could have
adverse effects if the timing is off (i.e. if you updated 1/2 of your
methods and commit, the other 1/2 of your methods may be required to
make the first ones loaded work). So, not recommended unless you know
exactly what you are updating (and it's a small update). Safest is to
stop the gem, update and start it again.

> 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:
>
> - that within a gem only ONE request at a time can be handled (also due
> to global transaction management)

Yes, but if your requests are handled quickly, a queue of requests can
be serviced in a short time. You can also start up a few gems and
multiplex over them. (Discussions on mailing list re. daemontools,
FastCGI and reverse proxy.

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

Yes, each request is a transaction on its own. In GS 3.1 you have
nested transactions with the ability to abort some changes. We
currently always commit (and validate before that).

HTH

I've just given broad explanations, please feel free to ask more questions.

Otto
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Am 19.11.2013 08:42, schrieb Otto Behrens:

>
>> -> Can I develop further on (in parallel) with Jade and DataCurator ?
>
> You can do that. But surely you may break the application while you
> are working if your end user is on it at the same time?
>

If the application is running under a different user, he should not see
the changes I made under user DataCurator !?
Some other questions:

All users can the see the contents available under "Globals" ?

A user "A" see its own/same contents of UserGlobals - even in different
concurrent sessions  ? a e.g. user "B" can not see the content of
UserGlobals of user "A" ?

Its uncommon to use Smalltalk processes - as they are used in other
Smalltalk environments - instead one should user worker gems to do heavy
background job !?

If you have heavy calculation stuff one should consider exporting the
computational data for background work in a non-Gemstone programming
environment - to get most of the 2-cpu-limitation !?

Persistence is done by reachability - therefore the programmer must
create a global persistent object, from which all other (persistent)
application objects can be reached.This can be achieved via global
entries in the UserGlobals directory or Globals - or perhaps much better
in a class (instance) variables ?

Some more questions to come :-))) Thanks for answering ...


Marten Feldtmann













.
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

It depends on how it is set up in the database. Some things can have
shared visibility, others not. In short, if you are really familiar
with GemStone, you can try this out, but I think this is treacherous
ground.

Shortly, here's how it works:

- Every user has his own symbol list (System myUserProfile
symbolList). A symbol list is a list of dictionaries that contain the
visible symbols (i.e. any class name & global variable). Some of the
dictionaries (called SymbolDictionaries) are shared (eg. Globals) and
some may be kept private (UserGlobals).
- Classes in GemStone are instances of Metaclasses, the same way that
it is in other Smalltalks. But, because of this setup, you can have
multiple concurrent instances of classes with the same name. Or global
variables with the same name, but not pointing to the same object.
- This means that user A can have an instance of class Foo and user B
as well, but they are different classes. Where the difficulty comes in
is that if you encounter instances, which class are you looking at? If
you update the code of Foo, you are updating the code of the class in
your symbol list. This will not affect instances of Foo which are in
the other user's symbol list.
- You may share the UserGlobals symbol dictionaries between users if
you set it up like that.
- Classes are kept concurrently when class definitions are updated
(see classHistory on a class). Migration is a process to get instances
from one class to another. This can be heavy if there are lots of
objects / big database, or you can use the auto migration.

> Its uncommon to use Smalltalk processes - as they are used in other
> Smalltalk environments - instead one should user worker gems to do heavy
> background job !?

Yes

> If you have heavy calculation stuff one should consider exporting the
> computational data for background work in a non-Gemstone programming
> environment - to get most of the 2-cpu-limitation !?

If your 2 CPU's are being eaten up by other things and does not focus
on the computation, then you can do that. But I'd think you must have
a very heavily loaded system with heavy computations to justify that.
I'd build it in Smalltalk and then handle it when I get there.
Alternatively, when you get to that point, it may make sense to buy a
license.

> Persistence is done by reachability - therefore the programmer must
> create a global persistent object, from which all other (persistent)
> application objects can be reached.This can be achieved via global
> entries in the UserGlobals directory or Globals - or perhaps much better
> in a class (instance) variables ?

Yes, class instance variables are better. Some people believe in a
global class that contains your data (perhaps a singleton). I like
have selected classes manage their instances in a class inst var.
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Martin,

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

On Nov 19, 2013, at 8:56 AM, [hidden email] 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


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Nov 19, 2013, at 10:16 AM, [hidden email] wrote:

> If the application is running under a different user, he should not see
> the changes I made under user DataCurator !?

As Otto has described, that depends on where you put the data. Each user gets his or her own UserGlobals, but by default each user shares the same Published. Published is the designated place to put application classes and data that you want to share (by default, you can, of course, add other dictionaries to anyone’s SymbolList).

Although, I wouldn’t use separate users. It just introduces (usually) needless complexity.

> Some other questions:
>
> All users can the see the contents available under "Globals” ?

Yes, unless someone removed Globals from the user’s SymbolDictionary (which would be very strange).
>
> A user "A" see its own/same contents of UserGlobals - even in different
> concurrent sessions  ?

As long as the first session commits and the second session does an abort or commit, then they see the same data.

> a e.g. user "B" can not see the content of UserGlobals of user "A” ?

Generally not, unless you reference user A’s UserGlobals from user B’s SymbolList (which would be very confusing).

> Its uncommon to use Smalltalk processes - as they are used in other
> Smalltalk environments - instead one should user worker gems to do heavy
> background job !?

If you are willing to have GemStone behave like other Smalltalks, then you can do everything in one Gem. The value of separate Gems is that it takes advantage of the GemStone feature of transaction isolation.

> If you have heavy calculation stuff one should consider exporting the
> computational data for background work in a non-Gemstone programming
> environment - to get most of the 2-cpu-limitation !?
>
> Persistence is done by reachability - therefore the programmer must
> create a global persistent object, from which all other (persistent)
> application objects can be reached.This can be achieved via global
> entries in the UserGlobals directory or Globals - or perhaps much better
> in a class (instance) variables ?

This is a bit more of a judgment call. At one time class (instance) variables were not copied from one class version to another. So, if you added an instance variable to your class then all your persistent data disappeared. (Of course, it was still there, but not in the current version of the class so it looked like it was gone and it was a little complicated to get it back.) We have fixed that problem, so class (instance) variables are no longer quite such a bad idea.

My current approach is to have an application manager class where an instance holds the key application objects (primarily collections). On the class side are methods that answer the default and current application and allow you to set the current application. The default application would be the production one while the current application (which defaults to the default) is stored in a SessionTemp. This allows you to use a temporary application object for testing, and you can even run tests in production (though I wouldn’t recommend it!).

The default application object can be in a class (instance) variable or in a global. Because of the earlier problems with variables being lost when a new version was created, I got in the habit of using a global, and I still lean that way but can’t think of a compelling reason right now.

> Some more questions to come :-))) Thanks for answering …

It is fun to hear what you are doing. Keep it up!

> Marten Feldtmann

James

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass