On Feb 24, 10:20 pm, Isaac <[email protected]> wrote:
> Well, the best explanation I have is that these values are how I want
> the Session to behave, which is why I put a comment saying you may
> want to put something else there.
That's what I was following up :-)
> Maybe some other values are more sane for a typical or smaller app
> than the one I'm working on at the moment (which is not small, and
> probably not typical).
My reading of the SQLA docs suggests that the default values try to
strike a balance between improved operational reliability and
increased developer convenience. I just wondered if you thought that
your app had some particular characteristics that prompted your choice
--- "not small, and probably not typical" sounds like it fits the
bill.
> I suggest reading <http://www.sqlalchemy.org/docs/05/reference/orm/
> sessions.html#sqlalchemy.orm.sessionmaker
Indeed. But Mike (understandably) barely hints at the operating
conditions that might prompt the adoption of a flush/commit strategy
other than the default. I write "understandably" because the
complexity introduced by the different characteristics of the various
relational persistences supported by SQLA probably places the matter
outside the scope of the SQLA docs.
> try them out, and then decide what's right for your situation/app.
That's a long and potentially expensive process. I'm just sculling
around trying to get a bead on things. I found this to be a useful 6-
or-so scrolling pages:
https://rhstack.108.redhat.com/articles/2007/02/09/design-issues-in-high-performance-transactional-applications-using-Java-and-Linux.html
(for others' reference) it's fairly well-packed: "differences in how
databases handle concurrency", "whether the database supports native
operating system threads (NPTL) or processes.", "Generally, synthetic
keys (sequences, auto-number) are preferred to business keys as
primary keys", "It is also best if analytical schemas (such as those
used for monthly reporting systems) are kept separate from your
operational system schemas."
Partly answering my own (idle) question:
"Another thing to watch out for with persistence solutions is when and
where they "flush." Most persistence solutions gain a performance
advantage by scheduling updates and inserts to be sent to the database
"lazily." By default, in Hibernate, this happens just before a query
is executed or just before a transaction actually commits at the
database level. The data must be flushed to the database just before a
query to assure accurate results.
Flushing is expensive. Most solutions do this generically without
noticing which entities are actually retrieved. You can potentially
gain a performance advantage by toggling the flush mode when you "know
it's safe" (e.g. not on large projects with lots of developers of
various skill levels); or by ordering your operations smartly to
execute non-dependent queries together before updates (although this
may be difficult to muster in a proper object-oriented/service-
oriented design). Playing with the flush mode and scheduling queries
is also how you can potentially run less sophisticated databases which
still use row locking in a lower isolation level (with a lot of
specific work) to achieve higher concurrency."
I still need to figure out how that plays back into my choice of
sessionmaker kwarg values but at least it's no longer an idle
question.
Thank you, Isaac.
Cheer,
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
