Hi Joachim,
On Tue, Nov 10, 2020 at 3:01 PM jtuchel <
jtu...@objektfabrik.de> wrote:
>
> Esteban,
>
> we have a very similar architecture: every Seaside session has its own GlorpSession. They all share a single DB connection. This has been working for quiet a while and has never shown to be a problem. I am aware that we can hit a wall here, but we run enough images in parallel, so that we have some way to go before that.
I never thought of sharing a single connection among different
GlorpSessions, is it a connection or a "transparent" connection pool?
I guess that since it's read only you don't have to deal with
transactions happening in different sessions (seaside/glorp).
> I can think of a workaround for this, but am not sure if that's really a good idea. I'll just draft it here.
> When these two know each other, you could think of a variant of registerTransitiveClosure: and friends . Whenever the active session needs to decide whether an object is to be inserted or updated, it first looks at its own registeredObjects. If the objects is there, evreything works like it does now. But if not, it asks the passive Session if the object is registered there. If so, it registers the object with itself and continues like before.
> Sounds easy for me at first glance, but I am sure I am not understanding all the consequences this may have. Not sure about deletions, for example. Or differing lock keys (these will probably work like they do now?).
>
> Ideas? Counter-arguments?
Well... it doesn't sound easy for me, that's not a counter argument at
all, but sometimes you hit limits with ORMs, and GLORP is programmed
in a way to make everything transparent (saves, deletes, etc.), but I
find the way of doing such stuff overwhelming for my use case.
In the context of a long lived stateful session such as a desktop app
or a continuations based Seaside app, then that model might work well,
but in a request/response world, having a good balance between
"recreate the world" and "have everything in memory" is paramount,
what seems to be missing is a "layering" of sessions for such
scenarios.
As a little contextual information, when doing this "in haus" ORM
(~2005) I did look at other popular ORMs, I remember that I was
impressed with Java's Hibernate because it has this concept of
intermediate cache/session, where the end user session was connected
to the "global" cache, but it let each user session to work as you
currently do with Glorp, with the benefit that if you modify one
object in other session, all other sessions were notified about it.
How it did that is beyond my understanding, and if the
DescriptorSystem is hell sometimes, well.... doing the same with XML
was like hitting your fingers with a hammer.
Of course this is a pipe dream for the current use base of Glorp, any
modification in this direction would mean a complete overhaul with an
open ended outcome.
Regards,