On Jun 18, 2008, at 11:43 AM, Hans wrote:
> > Now, if I want to do some stuff with the engine or connection > directly, should I create my engine with context="threadlocal" > additionally? (And then pass that threadlocal engine off to my > scoped_session ?) if you deal with the engine, it uses connection resources on an as needed basis, such as when you say engine.execute(somestatement). the "threadlocal" context doesn't really grant any additional "thread safety", its just a convenience method so that operations common to a thread can all implicitly share a transaction without the need to pass an explicit Connection object. It is typically useful in a non-ORM oriented application. In an ORM oriented application, the Session tends to be the home base for transactional/database context. Im not entirely sure what you mean by "pass that engine to my scoped_session". You typically bind the underlying sessionmaker() to an engine when its first created, "threadlocal" or not, and you're done. > And when I get a connection from such an engine, do I need to always > specify that I want a contextual connection? i.e. conn = > engine.contextual_connect() ? (What happens if I just run > engine.connect() as "normal" with a threadlocal connection?) the difference between connect() and contextual_connect() is only significant if you're using the "threadlocal" context. I would advise not using "threadlocal" for now as you should familiarize with the basics first. If you are using Connections, its best to stick with connect(). contextual_connect() is only for applications that are trying to interact with the engine in such a way that they participate within the "threadlocal" context if used that way. But normally you wouldn't use explicit Connections with "threadlocal" since the whole point of "threadlocal" is to remove the need to pass around Connection objects. I would comment that if you are working with ORM transactions and wish to have direct execute() access within the context of that transaction, you're best sticking with the execute() and connection() methods off of Session itself; this will ensure that those operations are participating with whatever transaction the current Session may have in progress. > I assume all of this is necessary in a multi-threaded environment? just dont share a single Session or Connection between threads, and you're good to go. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" 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/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
