How is this better than a read then a write outside of a transaction ? Anyway it looks like there will be specialized tasks for transaction across entity groups in the future.
On Dec 1, 4:32 am, peterk <[email protected]> wrote: > 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.
