tblanchard at mac.com
Fri Dec 14 22:33:29 UTC 2007
Yeah, you know a little article on developing for Gemstone without
Gemstone would be really useful for people considering making the
jump. At least folks could be getting ready to adopt.
On Dec 14, 2007, at 10:41 AM, Dale Henrichs wrote:
> 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 that directions.
> 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.
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside