dale.henrichs at gemstone.com
Fri Dec 14 18:41:20 UTC 2007
As others have mentioned you need to have the 64bit hardware to run
GemStone. There would be a significant amount of work for us to port our
64bit product to run on 32 bit architectures, so we won't be heading in
We have recently announced a non-commercial version of GemStone 6.2 is
available for the Mac (Tiger on x86). GemStone 6.x is the 32 bit line of
our server. This is an option that could be followed.
On the other hand, if you are developing an application (with plans to
deploy on GemStone), then it is actually a very good strategy to develop
in Squeak and deploy in GemStone. Our first GLASS customer to go into
production did just that. They started developing their application in
Squeak long before we even a beta ready for GemStone (in fact they did
their development using Seaside2.7), then when we had our beta ready
they ported their application from Squeak to GemStone (using Seaside2.8).
As Boris has mentioned, taking advantage of GemStone persistence is as
simple as storing things in class variables. Anything that is kept alive
in your Squeak image will be kept alive (and persisted) in GemStone. In
a Seaside application, the framework does the commits, so there is
literally no need to change you application when you move it to
GemStone. A good set of unit tests is recommended, but then thats a good
idea no matter what your deployment plans are.
You _do_ have to be more aware of concurrency issues in a GemStone
application than you do in an image-based application. Intra-session
data structure access is protected by object locking in the framework,
but for data structures that may be updated by multiple sessions (places
where you would be using Semaphores to protect data access in a Squeak
Seaside application) you will likely need to use some GemStone-specific
reduced conflict classes. I have plans to write a blog post to cover
the options in more detail - after today's discussion, I will probably
write it sooner rather than later.
In general, you will be doing very little GemStone/persistence-specific
code in a Seaside application that is targeted to be deployed in GemStone.
In the end, I think it is very possible (and even desirable) to develop
your Seaside app in Squeak with plans to deploy in GemStone. I would
think that you can get away with doing quite a bit of development,
before really needing to get access to GemStone and 64 bit hardware.
More information about the seaside