I'm not sure if this would meet your needs or not, but it might be something to look into. A book I was reading suggested transactional enqueuing of tasks to get around having to keep all entities in a single entity group, for certain kinds of transaction.
So say in a transaction you need to read from one entity and write to another. Using this method you could in a transaction read from the first entity, and then enqueue a task to write to the second. The two entities can be in different entity groups, but the transaction will ensure that the write task doesn't get enqueued if the read on the first entity fails. So if the read fails, the write will fail. The book notes that at the time of writing transactional task enqueuing was not supported, but this may have changed by now (?) You'd also be limited by the quotas and limits currently applicable to the Task Queue. And it wouldn't be suitable for all kinds of transactions...for example, I'm not sure how you'd cast a problem of needing 3 writes in a single transaction to this technique. You could enqueue three tasks in a transaction, but you've no visibility beyond that of the writes' success. On Nov 27, 3:40 am, 风笑雪 <[email protected]> wrote: > I just watched some Google I/O videos about GAE yesterday, and I have > 2 questions about transaction. > > Assume I need to build a bank system, two clients (Alice and Bob) want > to transfer one's money to the other. > So when I create Alice and Bob, I must put them in the same entity group: > alice = User(name='Alice') > bob = User(parent=alice, name='Bob') > > If I have millions of clients, and they all have a chance to make a > deal with each other, then they should be all in the same entity > group: > adam = User(name='Adam') > alice = User(parent=adam,name='Alice') > bob = User(parent=adam, name='Bob') > chris = User(parent=adam, name='Chris') > ... > > As the presentation says, writes to the entity group is serialized, > and a write operation takes at least 10ms, a transaction needs at > least 1 reed and 3 writes, so I can't do more than 33 deals/sec, is it > scalable enough? > And having such a big entity group may easily cause high contention, > maybe most of the transactions will fail. > I wonder how could I break the huge group into small entity groups? > > The second question is about the root entity. > The presentation says, root keeps a timestamp for the entire group. > But document also says, we can delete an ancestor, or just create a > Key for the ancestor that not exist to specify the parent of the new > entity. > So if the root has been deleted, or not exist at all, can this entity > group still transactional? -- You received this message because you are subscribed to the Google Groups "Google App Engine" 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/google-appengine?hl=en.
