On Wednesday, April 17, 2013 2:31:48 AM UTC-7, Aymeric Augustin wrote: > > 2013/4/17 Daniel Swarbrick <daniel.s...@gmail.com <javascript:>> > >> On the pure Django side of things, one of the challenges I encountered >> was "IDLE IN TRANSACTION" hanging DB connections in the long-running >> WebSocket views. I really ought to research a more elegant solution to >> this, but for now I'm just doing all my DB queries early in the view, then >> fairly brutally closing the DB connection before entering the long-running >> WS poll loop. >> > > The new transaction management introduced in Django 1.6 may help with this > problem, but it isn't a good idea not to maintain one database connection > per websocket on a website with more than a few users anyway :) > > I believe you need a connection pooler and asynchronous database I/O if > you want to talk to the database from a websocket handler. I haven't looked > at this in detail. >
A difficulty will be moving beyond simple demos to something that can be more widely and immediately useful and allow for moderate scale. The first real challenges happen in scaling beyond one app server process, as you now start dealing with arbitrating state change collisions. These are less of an issue in more atomic, transaction based request response designs - where you expect state may change between page refreshes. I've got a bunch more research to do, but I've been making some notes in this area - some fun geek concepts that are potentially involved: paxos, operational transformation, software transactional memory, vector clocks etc. Relying only on the ORM and stock backends will be challenging to support distributed concurrency. Here is a micro manifesto on my thoughts of Django and realtime: Many/most sites don't need all pages/views to be realtime backed, so for many projects traditional Django usage will continue to work just fine, this is Django's heritage and strength. Making use of Django components (ORM, templates?) in a realtime context should be facilitated. Django should continue to focus on making the common cases relatively easy, while not getting in the way of the more elaborate or complex needs. Django shouldn't ship any stock solution initially in core, and if/when it does ship something, it should be built on clean and fundamental abstracted layers that allow others to continue to innovate without needing to reinvent the truly common low level parts. In my own digging, I haven't found anything so far at the low level that would need to be added to Django itself. The possible exception is the predicate stuff, and I do still hope to get that work in after Anssi's lookup refactor work is completed. There is the issue of how much model logic gets moved to Javascript, and how integrated vs loosely coupled the JS should be from the Python code. On one end would be just standardizing on a wire protocol like Meteor's DDP or something similar. At the other end would be building on top of that and having something that let you declare a ModelForm like class in Python, which when used via a special template tag, would magically become a client side representation in the browser and automatically set up all the realtime data exchanges to the Django model. Those obviously don't have to be mutually exclusive ideas - in fact the latter should be based on something like the former. So we need to continue the period of exploration - I do think Tulip looks promising enough to start planning a future on - but there will be many design components that won't need to exist at the tulip calling level, or would be relatively easy to port. To paraphrase something Jacob said after the Meteor keynote at DjangoCon `I know that in <n> years, I'll be using something that works like Meteor - I hope that something can be Django'. -Preston -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
