[appengine-java] Is it guaranteed that App Engine retries a task until it succeeds.
Could google developers clarify the next: 1)Documentation says: If a task fails to execute (by returning any HTTP status code outside of the range 200-299), App Engine retries until it succeeds. But It is not clear if it is guaranteed or not. E.g. GAE retries a task for the 5 time and the task is failed again. But after GAE doesn't retry a task for the 6 time and the task is undone permanently. Can this use case happen? Does a developer generally have to handle such use cases in the app or not? 2) From : http://code.google.com/intl/uk-UA/appengine/docs/java/taskqueue/overview.html#Tasks_Within_Transactions Tasks added within a transaction are considered to be a part of it and have the same level of isolation and consistency. What does it mean: [have the same level of isolation and consistency] ? When should I care of that in my app (an example)? -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: How to simulate transactional behaviour for two root entites?
I am agreed with you about these things. But in documentation I didn't find anything that says that all needed task retries are guaranteed. ---Second, about your question, tasks within transactions are guaranteed: --You can enqueue a task as part of a datastore transaction, such that -the task is only enqueued—and guaranteed to be enqueued—if the -transaction is committed successfully. Source: -http://-ode.google.com/appengine/docs/java/taskqueue/ overview.html#Ta..., That says that tasks are guaranteed to be enqueued but that doesn't say that tasks are guaranteed to be done after they have been enqueued. E.g. Task failes 100 times and there is not a retry attempt for 101 time - task is undone forever. Please, correct me if i am wrong! -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: I need to do a cron without 30 sec limit
I also have a similar task. Please, could you clarify in more details how to use Task Queue API and datastore cursors? it is also good that task execution's limit is 10 minute now. On 21 Січ, 20:03, mge...@gmail.com wrote: For sure Mapper API is a really good choice. Another option would be using Task Queue API and datastore cursors. Both options will solve your problem. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] How to simulate transactional behaviour for two root entites?
I have the next problem: My app has thousands of users. Every user has money that can be represented as the money field in the User entity. If a payable event occurs in the app then I have to make a payment between two users so I need to update money fields for two User entities in a transaction. But I can't do it in a transaction because each user is in a different entity group and on the other hand I cann't put two users in a single entity group, because thus the single entity group will have all users and datastore contention problem will arise. I can't figure out how this use case can be implemented correctly or how to design a datastore model. Please, suggest best practices for this situation! -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: How to simulate transactional behaviour for two root entites?
First of all, thanks very much for quick and reasonable replys! --What is not guaranteed though is a rollback on the --1st update if the second fails or can't happen But it is guaranteed that the 2nd update can be rolled forward once to infinity or the 1st update can be rolled back(probably via a 3rd task) once to infinity. To accomplish that we should configure the queue to retry every e.g. 20 sec. and retring will continue to infinity unless the task is fulfiled. From this perspective my use case can be considered consistent for the duration of infinity. Am I right? --You have to use distributed transaction as described in --http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engine Actually the approach in this article is the same as Didier described except we should manually controll rolling forward(back) in our code. So it is better to use Didier's method because every method doesn't have any advantages over other but Didier's method is more easy to implement. Am I right? Anyway, these methods don't guarante real transactional consistency. And as far I understand there is not any other real transactional solution. Am I right? -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] What exception raises if there are timeouts due to write contention?
What exception raises if there are timeouts due to write contention? According to this: http://code.google.com/intl/uk-UA/appengine/articles/handling_datastore_errors.html. It's likely appengine.ext.db.TransactionFailedError. But I cann't find this class in appengine libs. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Are static fields(blocks) invoked during a loading request?
Accoring to this: http://code.google.com/intl/uk-UA/appengine/docs/adminconsole/instances.html#Loading_Requests during a loading request JVM loads only classes required to handle this request. i.e. if I have class A and the loading servlet class(which is invoked during a loading request) doesn't have import A statement at the top then class A won't be loaded by JVM during a loading request. Am I right? Secondly, static fields and blocks of the underlying app which are not required to handle a loading request are invoked during this request? -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Are static fields(blocks) invoked during a loading request?
Thanks! Your question is important when high activity happens to your application and many jvm instances are started: you cannot rely on static fields to store shared values across the entire application as they are locally initialized in each instance. I am aware of that. I use static statements for common things of one jvm instance. e.g. to define constants. It is better to make this sort of initialization once at the startup than during every request. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Check existence: datastoreservice.get(key) or __key__ property query(keys-only) or ancestor query(keys-only)?
Let's suppose I need to check by a key if the specified entity exists in the datastore. What is the most proper way to achieve that?I have the next ways: 1) datastoreservice.get(key). 2) execute keys-only query with the __key__ property: new Query(Kind).addFilter(Entity.KEY_RESERVED_PROPERTY, FilterOperator.EQUAL, key).setKeysOnly() 3) execute keys-only query with the ancestor key: new Query(Kind).setAncestor(key).setKeysOnly() I think that 2) or 3) is more efficient than 1) because we don't need to deserialize the whole entity from the datastore, just get only keys. But I don't have any suggestions about: 2) or 3) is more efficient? -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Check existence: datastoreservice.get(key) or __key__ property query(keys-only) or ancestor query(keys-only)?
You're right about 2): more efficient because only key is accessed: i/ o limited to index rather than index + table when you fetch the entire entity. So more disk i/o and more bytes to transfer between the datastore server and the server of your jvm. OK About 3): 2 important points come to mind: (a) using ancestor key means that you know how your entities are grouped in the datastore for transactional purposes: i.e you need to know the parent for each entity key you want to check But I also need to know the parent key for '2)' way. What is the difference? and (b) according to this grouping, get on 1 ancestor key may return more than 1 child entity and then you may lose the performance optimization that you are looking for. When I call setAncestor() I pass the complete key: all parents keys + the entity key. So query can't return more than 1 entity. So I don't see the benefit from '2)' way accoring to your reply. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Check existence: datastoreservice.get(key) or __key__ property query(keys-only) or ancestor query(keys-only)?
I've got your idea. The '2)' way is more flexible, because using '3)' we should guarantee that the key is complete and the key is not an ancestor for other entities(extra constraints for the app). So now I'm agreed with you that '2)' way is a choice. Thanks, very much! -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: low-lewel put method outside of a transaction
Thanks very much. That is exactly what I need.
On 22 Грд, 23:49, Stephen Johnson onepagewo...@gmail.com wrote:
You might want to take a look at CommittedButStillApplyingException
On Tue, Dec 21, 2010 at 1:08 PM, ss.require ss.requ...@gmail.com wrote:
Please, help!
According to this:
http://code.google.com/intl/uk-UA/appengine/articles/life_of_write.html.
Let's suppose that I call the low-level put method outside of a
transaction and an exception throws. If exception occures at the
commit phase entity won't be saved otherwise if exception occures at
the applyed phase entity will be saved.
Is there a way to find out entity is really saved or not in the
datastore after exception?
If I execute the same operation inside a transaction, for exampe:
Transaction tx = datastore.beginTransaction();
try {
put entity code ...
tx.commit();
} finally {
if (tx.isActive()) {
tx.rollback();
}
Suppose exception occures in the apply phase, then tx.rollback() will
be fired? Can it make sure that enitty really won't be saved in the
datastore?
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to
google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2b-unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: What sort of indexes does GAE use for queries that use only equality and ancestor filters?
I've already found the answer by myself. The answer is here: http://www.google.com/intl/uk-UA/events/io/2009/sessions/BuildingScalableComplexApps.html. Just few words. For queries with multiple equality filters GAE uses merge-join. GAE scans single indexes for every equality filter in the query and merge results. For more details you can see very helpful video by the link above. On 19 Грд, 17:53, ss.require ss.requ...@gmail.com wrote: Documentation says: App Engine provides automatic indexes for the following forms of queries: queries using only equality and ancestor filters For implementation of this feature GAE uses single-property indexes or composite indexex or something else? If composite indexexes then how many indexes are used (for example: all possible permutations for properties)? -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: What sort of indexes does GAE use for queries that use only equality and ancestor filters?
But I can't figure out what index(any other mechanism) GAE uses for query with only one ancestor filter? I want to know what is efficient for one-many relationship: store a reference to an opposite object as a simple reference property(Key object) or store one in the primary key as the parent key? On 23 Грд, 16:30, ss.require ss.requ...@gmail.com wrote: I've already found the answer by myself. The answer is here:http://www.google.com/intl/uk-UA/events/io/2009/sessions/BuildingScal Just few words. For queries with multiple equality filters GAE uses merge-join. GAE scans single indexes for every equality filter in the query and merge results. For more details you can see very helpful video by the link above. On 19 Грд, 17:53, ss.require ss.requ...@gmail.com wrote: Documentation says: App Engine provides automatic indexes for the following forms of queries: queries using only equality and ancestor filters For implementation of this feature GAE uses single-property indexes or composite indexex or something else? If composite indexexes then how many indexes are used (for example: all possible permutations for properties)? -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] low-lewel put method outside of a transaction
Please, help!
According to this:
http://code.google.com/intl/uk-UA/appengine/articles/life_of_write.html.
Suppose I call low-level put method outside of a transaction and after
an exception throws. If exception occures at the commit phase entity
won't be saved otherwise if exception occures at the applyed phase
entity will be saved.
Is there a way to find out entity is really saved or not after
exception?
If I execute the same operation inside the transaction, for exampe:
Transaction tx = datastore.beginTransaction();
try {
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] low-lewel put method outside of a transaction
Please, help!
According to this:
http://code.google.com/intl/uk-UA/appengine/articles/life_of_write.html.
Let's suppose that I call the low-level put method outside of a
transaction and an exception throws. If exception occures at the
commit phase entity won't be saved otherwise if exception occures at
the applyed phase entity will be saved.
Is there a way to find out entity is really saved or not in the
datastore after exception?
If I execute the same operation inside a transaction, for exampe:
Transaction tx = datastore.beginTransaction();
try {
put entity code ...
tx.commit();
} finally {
if (tx.isActive()) {
tx.rollback();
}
Suppose exception occures in the apply phase, then tx.rollback() will
be fired? Can it make sure that enitty really won't be saved in the
datastore?
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] What sort of indexes does GAE use for queries that use only equality and ancestor filters?
Documentation says: App Engine provides automatic indexes for the following forms of queries: queries using only equality and ancestor filters For implementation of this feature GAE uses single-property indexes or composite indexex or something else? If composite indexexes then how many indexes are used (for example: all possible permutations for properties)? -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
