It’s Alive! GemSource is on the air.

If you are interested in poking around in the source code for the GemStone port of Monticello, Seaside, or SqueakSource then you should cruise around GemSource. The site was just brought on-line this afternoon and it will be our primary repository for GemStone/Seaside source as we move forward.

GemSource is ‘read only’ at the moment, but as soon as we start the Beta, we’ll open up access to the site for all users and projects. If you are interested, I encourage you to register for an account, so you can view the package contents from the comfort of you own Squeak image.

If you do decide to take a look from Squeak, you’ll need to make the following change to MCClassDefinition>>kindOfSubclass in your Squeak image:

kindOfSubclass
  type = #normal ifTrue: [^ ' subclass: '].
  type = #words ifTrue: [^ ' variableWordSubclass: '].
  type = #variable ifTrue: [^ ' variableSubclass: '].
  type = #bytes ifTrue: [^ ' variableByteSubclass: '].
  type = #weak ifTrue: [^ ' weakSubclass: ' ].
  type = #compiledMethod 
    ifTrue: [^ ' variableByteSubclass: ' ].
  type = #transient ifTrue: [ ^ ' variableSubclass: ' ].
  self error: 'Unrecognized class type'

I’ll be checking that change into SqueakSource in a day or so.

I’m only a third of the way through the “Make It Work, Make It Right, Make It Fast” cycle, so it would be premature to incorporate any of my changes into the Squeak version, but if any Seasiders, see something interesting or odd, don’t hesitate to let me know. I’ll take credit for the interesting bits and find some excuse for the odd ones.

Right now, GemSource is running with a single GemStone Seaside VM (behind Apache) and a maintenance VM (as described in Porting Application-Specific Seaside Threads to GemStone).

In the coming weeks, I will use GemSource as the sample application when I describe a technique for dealing with long-running HTTP requests, and I describe how to avoid concurrency issues when moving an application to multiple VMs.

I know of at least twoone funky problems with the site: wierd component nesting in some cases and the handling of batched lists is broken. Both of t. These problems are directly related to the fact that GemSource was ported from an earlier version of Seaside (2.3 or older). I may need a little help from a Seaside expert to figure out how to fix these two problems (hint, hint…).

In other cases, some html has leaked into the page – again this is due to the change in behavior between Seaside2.3(?) and Seaside2.6. These problems will be fixed shortly.

If you notice anything else that is odd, drop me a line at our Beta mailing address (see GLASS) or submit a comment to this post.

Updated (5/26/2007): With Philippe’s help I was able to fix the broken batched list problem and I’ve updated the site.

The Terse Guide to GemStone Smalltalk

Last week Ramon Leon asked, ‘Where’s the “Terse Guide to Gemstone”?‘ and today I can give him the answer.

In addition to the “Terse Guide to GemStone” you can find links to official GemStone documentation on my docs page.

If, after reading some of the documentation, you find that you have more questions about GemStone, feel free to write comments to this post or you can join the GemStone Mailing list. A number of long-time GemStone users monitor the list (in addition to the GemStone engineering staff) and I’m sure they will be glad to answer your questions.

This week I’ve been ‘heads down’, getting GemSource (the port of SqueakSource to GemStone) ready to go live, so I haven’t had a lot of time to write.

When GemSource goes live next week, it will be a read only site (at first), but we will have published all of the packages (Monticello, Hyper, FastCGI, Seaside, and SqueakSource) for your enjoyment.

See you at ESUG 2007

Monty Williams, James Foster, Martin McClure, and myself will be representing GemStone at ESUG this year. I’m looking forward to getting a chance to meet folks from the European Smalltalk and Seaside community.

GemStone/S Training Course Announced

We’ll be holding two courses this summer in Beaverton, Oregon (GemStone world headquarters):

• GemStone/S Fundamentals (July 16 -19, 2007)
• GemStone/S Advanced Programming Practices (July 9-13, 2007)

Most of the people moving their Squeak/Seaside applications to GemStone/S shouldn’t have to take the course, however, if you’re planning on running a large GemStone/S installation or would like to geek out with GemStone/S then read on….

Porting Application-Specific Seaside Threads to GemStone

If you are using threads (forking Smalltalk processes) in your Seaside application, then you will need to make some relatively minor mods to your code.

In addition to managing concurrent access to objects (via critical blocks), all threads must be coordinated in relation to transaction boundaries. You cannot afford to have multiple threads aborting and committing without some sort of coordination – the method SeasidePlatformSupport class>>doTransaction: provides that coordination.

SeasidePlatformSupport class>>doTransaction: acquires the transactionMutex, performs a beginTransaction, evalutes the block passed in as an argument, performs a commitTransaction and returns the result of the commitTransaction (a Boolean). The transactionMutex ensures that your transaction will not interfere with any other ongoing transaction, including servicing an HTTP request.

In the SqueakSource Seaside application, there is a CacheThread that runs once a day and the code looks like this:

startCacheThread
  self isCacheThreadRunning ifTrue: [
    self stopCacheTread ].
  cacheThread := [
    self updateCache.
    self updateStatistics.
    (Delay forDuration: 1 day) wait.
  ] forkAt: Processor userBackgroundPriority

After adding a call to SeasidePlatformSupport class>>doTransaction:, the code looks like this:

startCacheThread
  self isCacheThreadRunning ifTrue: [
    self stopCacheTread ].
  cacheThread := [
    SeasidePlatformSupport doTransaction: [
      self updateCache.
      self updateStatistics.
    ].
    (Delay forDuration: 1 day) wait.
  ] forkAt: Processor userBackgroundPriority

If you choose to run the thread in the same VM as the Seaside application, you need to pay attention to how much time you spend inside of a doTransaction: block, because HTTP requests won’t be serviced while the block is executing.

If you’ve got long running transactions, then you should unconditionally move the thread into a separate GemStone VM. In the separate VM, the transaction duration will not affect the response times for HTTP requests.

Here’s an sample topaz script for running this thread in a separate VM (I’ll cover topaz in more detail in another post):

!
! Sample script for updating
!  SSRepository cache and statistics
!
set user DataCurator pass swordfish
login

run
!
! enter manual transaction mode and
!   install SigAbort handler
!
System transactionMode: #manualBegin.
Exception installStaticException:
      [:ex :cat :num :args |
        System abortTransaction.
        System enableSignaledAbortError ]
   category: GemStoneError
   number: 6009
   subtype: nil.
System enableSignaledAbortError.

!
! Start update loop
!
[true] whileTrue:[
   SeasidePlatformSupport
     doTransaction: [
       SSRepository updateCache.
       SSRepository updateStatistics.
   ].
   (Delay forDuration: 1 day) wait.
].
%

If you have more than one thread in your Seaside application, you can fork off additional processes in the script.

My recomendation is that you plan on moving all of your background threads to a separate VM. In the long run it will be simpler to manage your threads and you won’t have to worry nearly as much about how long it takes individual operations to complete.

Transparent Persistence for Seaside

One of the very nice features of GemStone is that you don’t have to do anything special to take advantage of persistence. With other smalltalk dialects (Squeak, VW, VA, and Dolphin) objects that are referenced by the global Smalltalk will be ‘kept alive’ in the image. With GemStone, any objects referenced by a persistent root (I’ll explain why I didn’t say ‘Smalltalk’ here in a later post) will be ‘kept alive’ and ‘automatically’ saved in the data base.

In a generic GemStone application you do have to explicily manage transaction boundaries using the following methods:

• System class>>beginTransaction
• System class>>commitTransaction
• System class>>abortTransaction.

For the GemStone port of Seaside, we have embedded the transaction boundaries in the Seaside framework, so you don’t have to change your application at all – a beginTransaction is performed when the request comes in from the http server and a commitTransaction is performed right before the response is shipped back out to the http server.

This means that while your Seaside application is responding to the request, you have an up-to-date ‘view’ of the object graph and any changes that you make to persistent objects will be committed to the data base, without any special coding on your part.

[Update 3/17/2008]

As you scale your application you will eventually be adding more Seaside vm’s to serve your pages and when you do, you will then need to worry about transaction conflicts. I’ll cover transaction conflict avoidance in a later post.

With recent modifications to the GemStone port of Seaside, it isn’t absolutely neccessary to avoid transaction conflicts. For most applications a Simple Persistence model is perfectly adequate.

GLASS: GemStone, Linux, Apache, Seaside and Smalltalk

Recently James Foster and I gave a talk at Smalltalk Solutions where we described the port of Seaside and Monticello to GemStone/S 64. In addition to the talk, GemStone Systems announced a free (as in beer) version of GemStone/S mainly aimed at folks who are developing Seaside applications in Squeak and need to add persistence to their application.

Needless to say the announcement generated a fair amount of buzz.

For those of you unfamiliar with Gemstone/S especially in relation to Seaside, then you’ve come to the right place! As time goes by I hope to provide a series of articles that will help you to successfully move your Seaside application into GemStone.

Update (5/11/2007): Here’s a link to the slides for the talk.