Embedded Magma database

[Keith Hodges]

Jerry Bell wrote:
> My understanding of Magma so far is very superficial, there is a lot
> of 'magic' happening right now.  I'm sure that will change as I get
> more experience with the system.  I've only seen the error I described
> a couple of times so far but I wanted to make sure I could handle it
> in a headless application, if it was not handled already.
>
> I have not worked in Squeak very much, and  I've never seen that
> warning idiom.  It looks simple enough.  But, I'm using the Magma
> seasideHelper (specifically, I'm using WAMagmaSoloAuto.) , so I'm not
> sure where to put the warning handlers.   Any suggestions are welcome!
I think that the warnings happen on the server side, when the image is
restarting. So there is no way to wrap them on the client side. Chris
says that he has sorted this.
> I believe I'd prefer to have my image start from a clean state with no
> existing Magma sessions.   I believe that is happening now, but I'm
> not sure.   I don't save the server image, I always either quit
> without saving the image, or the server might possibly be shutdown
> "dirty" without any warning.
The "Magma" control panel, lists all of the open sessions. Do you have
that working?
> Another question: I have a few "long running" operations which should
> be triggered from the web application, but which should run in their
> own background process without blocking the web interface.  
WAMagma (and subclasses) have a hook (in theory) which runs after the
seaside query has been serviced. I.e. it is non-blocking.

#postProcessRequest: aRequest returned: aResponse

Alternatively if you wish to spawn a background process, then it
should/could be spawned in the context of a dummy
WASession+Configuration. (WAMagma forApp: 'myapp') is provided for this
purpose.
> For example, I generate RSS feeds for some of my database contents. 
> What's the best way to handle this?   Currently i make a deepCopy of
> my target object, and fork the operation as a separate process with
> that copy.   If I need to access the database in that forked process,
> I use
>
> (WAMagma forApp: 'appName') rootAs: MyServerRoot
> Without the deepCopy, I believe I was attempting to access a Magma
> proxy outside of the Seaside session, and I would sometimes get magma
> proxy errors.
This is my guess - I think you are taking an object from one session and
using it in another, in the middle of this the first session may be
discarded, leaving the second thread with un-referenced object ids. Your
work around is to deep copy it in the context of the first session,
before forking.

The correct approach is to obtain your object from the database from the
correct managing session, i.e.

    newMagmaSession := WAMagma forApp: 'appName'.

    [ (newMagmaSession rootAs: MyServerRoot) getTheObjectIWant
writeToRss ] fork.

Alternatively, if you are using a WAMagmaShared helper in your
application. You could use

newMagmaSession := WAMagmaShared forApp: 'appName'.

This would use the same shared magma session as seaside is using, so the
data may already be cached in memory, but #aborts and #commits are
controlled with a semaphore.

> I think it might be better if I passed the unique ID of my target
> object to the new process, and let it use that ID to find the target
> object and access everything from the database through "direct access"
> instead of using a deepCopy.
>
> Also, how should I handle the "direct access"?  Is it ok to do a
>
> myDB := (WAMagma forApp: 'appName') rootAs: MyServerRoot
>
> the first time I need it, and then use it over and over again?  If so,
> do I need to do an abortSession on it from time to time to keep it up
> to date with changes from the web interface?
Yes, unless you use a shared session.
> Perhaps I should do an abortSession before each time I use it?   Do I
> need to do anything to close that session when the Squeak image quits?
In theory it can simply restart where it left off.

Thanks for checking this out, I admit it is a bit experimental in parts.

best regards

Keith
> Thanks,
>
> Jerry
>
>
>
>
>
>
>
>
> On Sep 14, 2008, at 11:04 AM, Chris Muller wrote:
>
>> After more thinking, there is a (fairly common!) scenario where
>> developers will not feel the need to wrap the MagmaServerConsole in
>> their own application-server wrapper.  In other words, just a plain
>> vanilla Magma server image.
>>
>> In these cases, a Magma server image is simply saved and exited while
>> its running, and this can even be performed remotely ("mySession
>> serverSaveAndExit").
>>
>> Under this case, when the server image is restarted, only Magma's own
>> startUp: code re-establishes the files and sockets, your application
>> code will not have the opportunity to handle any warnings if there are
>> any.
>>
>> I will fix that..
>>
>> - Chris
>>
>>
>> On Fri, Sep 12, 2008 at 7:12 PM, Chris Muller <asqueaker at gmail.com>
>> wrote:
>>> Hi Jerry, yes Magma may signal warnings which you will need to handle
>>> if you want to run headless.  Are you familiar with handling
>>> exceptions in Squeak?  Here is the pattern:
>>>
>>> [ ..do some squeak code.. ]
>>>   on: Warning
>>>   do:
>>>       [ : warning |
>>>       ..log the warning somewhere if you want...
>>>       warning resume ]
>>>
>>> Honestly, I'm curious why you would be receiving that particular
>>> warning..
>>>
>>>
>>>
>>> On Fri, Sep 12, 2008 at 4:15 PM, Jerry Bell
>>> <jdbell at oxfordmetamedia.com> wrote:
>>>> Hi,
>>>>
>>>> I'm building a simple web application with an embedded Magma
>>>> database which
>>>> will run on a headless Linux appliance.
>>>>
>>>> A few times while developing the system, I've had a dialog window when
>>>> starting Squeak which has asked me to OK a recovery of the Magma
>>>> database.
>>>>
>>>> Obviously I won't have a UI on this headless appliance.  What do I
>>>> need to
>>>> do to make sure all of those types of interaction are handled by my
>>>> application?
>>>>
>>>> Thanks,
>>>>
>>>> Jerry
>>>>
>>>>
>>>> _______________________________________________
>>>> Magma mailing list
>>>> Magma at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/mailman/listinfo/magma
>>>>
>>>
>
>
> _______________________________________________
> Magma mailing list
> Magma at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>