Re: Applause for ZODB! And a question: How do you get pending change info from a transaction object?

On Sun, Apr 29, 2018 at 5:22 PM, David Pesta <[email protected]> wrote:

> In Tornado, all things happen on a single thread:
> http://www.tornadoweb.org/en/stable/#threads-and-wsgi
>
> (Async/await can also be used in Tornado, but I'm pretty sure I can get by
> without that additional complexity for this.)
>

Oh gawd, here we go again. :)

Asynchronous I/O is great for .... I/O.

If you have blocking operations, then it breaks down.  This was why the
pre-Node norm was to use asynchronous servers to manage requests and thread
pools to get work done.

ZODB is fundamentally at odds with Asynchronous programming because loading
objects into cache is *transparent* by design.  This means that any object
access is potentially blocking.  The alternative is to stick an await in
front of every object access, which is gross IMO. (Await is a disease that
will likely take over most applications that use it.)


> So, filestorage really is a consideration of mine and possibly all I will
> ever need.
>

Do you know that only one process can access a file storage at a time?


> Although, I would definitely be interested in that hack (and later API)
> you mentioned that provides something for ZEO that is equivalent to
> newt.db.follow.
>

I'll add the API this weekend. (It will likely take a bit longer after that
for code review and release.)  If you're in a hurry, I can share the hack.


>
> In any case, given everything you said (which was great btw!), RelStorage
> Postgres would probably be overkill for me for a while. I'm just looking
> for the simplicity of the tools that ZODB provides for traversing objects
> in the graph without all the infrastructural overhead.
>

Cool. And it's easy to change your mind later.


> To that end, these are the tools that are known to me at this time for
> being notified of database updates.
>
> In raw note form:
> - transaction.manager.registerSynch(MySynch)
> - def beforeCompletion(cls, transaction):
> - transaction.get()._resources[0]._registered_objects (yes, checks for
> None along the way are important)
>

I strongly recommend against this approach.

I understand the concerns with that, as mentioned in this discussion:
> 1. Higher-level notifications at the application level might be better
> than sandwiching a mechanism between the application and the database. I'm
> guessing there are program organizational concerns and flexibility
> considerations that are behind this thought.
>

Possibly.  This is easier if you limit yourself to one process, but that's
impractical IMO.  Otherwise, you're adding messaging machinery, which adds
a lot of complication.


> 2. Transaction hooks only run on a single application server. (And other
> reasons.) Question: Since each of my database instances will be completely
> separate from one another and reside with the application on their own
> small application servers, do you foresee other complications? No need for
> a distributed database on separate machines or anything like that. Not
> desirable for this app. I think I'm in the clear there. Let me know if I
> understood you right, or if there are other concerns.
>

No. Please ... just ... no. You won't get any advice from me trying to bend
transaction hooks to your will.


> Let me know if I misunderstood anything. I am willing to take the time to
> get all this right from the start. However, if the above is fine as a
> stop-gap until later, that's good too.
>

Please don't waste your time with transaction hooks.

Jim

-- 
Jim Fulton
http://jimfulton.info

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.