[Seaside] Glorp/Seaside experience exchange on- or offline, anybody?

[Esteban A. Maringolo]

2017-10-01 16:40 GMT-03:00 Philippe Marschall <philippe.marschall at gmail.com>:
> Hi
>
> Let me start by mentioning that I don't believe any of these issues
> are Seaside specific. IMO these issues apply to any web framework
> using GLORP and even any web framework using an ORM in general. So it
> could be beneficial to investigate how other Smalltalk web frameworks
> (AIDA, ApeX, Iliad, ...) or even other languages solve this issue
> (JSF, Spring Web MVC, JPA/Hibernate).

I agree, in general.

The big difference is that Seaside works stateful, more like an
application server than a single request-process-response execution..
I don't know much about Spring or other Java based tecnologies.

> What is most concerning to me is how every object ever loaded with
> GLOP is tracked in the cache of the GLOP session. IMO this is wrong as
> most objects are read-only and never edited. These objects should not
> be tracked. This leads to a lot of unnecessary memory overhead. Only
> the objects that are actually edited should be tracked.
> I think of it this way, when a table or list of objects is rendered
> none the displayed objects should be tracked. Only when an edit link
> or button is clicked and an edit form is rendered then the edited
> object needs to be tracked and optimistically locked. If we track
> every object ever loaded then this simply leads to unbound memory
> usage. If caching has to happen for correctness then the cache should
> be flushed at the end of a request.

I'm not sure what you mean by "tracked"; one thing is the caching of
such objects, and a different one is the rowmaps that GLORP keeps to
detect modifications.

When GLORP reads an object from the database it builds a rowmap, which
basically is the array of "database data" used to build the object.  I
agree that if we could detect or deterministically define the classes
whose instances will not be modified, we could discard the rowmaps
once the instance has been created, saving some memory if the read
objects are many.

A different thing is the cache, which should be defined per class, so
a "Person" could be kept in the cache (weak, timed), but a
"PurchaseOrder" don't, however that is more a domain logic decision.
Because if you repeatedly access the PurchaseOrder, the I/O time to
fetch the data and build the object is an order of magnitude bigger
than many computations.


> Digging a bit into the GLROP documentation I don't think a unit of
> work should be active during the render phase. As far as I understand
> this should prevent any of the loaded objects from being tracked by
> being added to the cache. Only when an object is being edited should
> it be registered manually for tracking by the GLOP session.


You could work without a UnitOfWork (UoW) and only explicitly mark
(register) in the session which objects are going to be "tracked" for
persistance. What UoW does is to simplify that process by
automatically registering all objects read whitin the UoW.

I don't tie the UoW with the render cycle, the UoW is, in my case,
tied to a "single business logic unit" (hence, a UoW).
I load the objects without a UoW, however most of these objects are
going to be kept in the cache.
In some cases I perform the queries explicitly requesting "fresh"
versions, thus avoiding the cache hit.

If you're working with thousands of objects in a table (to use as
simple example), you could paginate those, the caching of the
previously queried pages will be determined by the caching policy or
the explicit flushes you performed along the way.

> However during the callback phase a unit of work should be active.
> This should be done automatically by a Seaside-GLORP extension. On a
> successful or cancelled edit the edited object should be removed from
> the cache again and the callback should be invalidated (ideally a one
> time callback is used).

In the callback phase you could need more than one UoW, that depends
on how you structure your code.

I wouldn't use a UoW defined elsewhere. Maybe you're thinking in what
GemStone does with the abort/commit transaction at every cycle.

> It would be good to hear from somebody with GLROP experience whether
> what I just wrote made any sense at all or is utter nonsense.

What I don't understand is the need to remove everything from the
cache in the context of a stateful application.
The purpose of the cache is exactly to save I/O time, which as said,
in the context of RDBMS can be the slowest of all.

The fine tune of the cache is, as with any other performance tuning,
dependent on your business model.

> I would also be open to attending some sort of meetup in northern
> Switzerland/southern Germany to discuss this in person.

Great!

Regards!

--
Esteban.