That's interesting. I was able to reproduce it for a bit yesterday. I will
try again today and see if it's still occurring.
On Friday, January 31, 2014 2:50:35 AM UTC-5, Lucian Baciu wrote:
>
> No, I did't find anything, the issue resolved itself apparently after
> about an hour.
>
> On Friday
No, I did't find anything, the issue resolved itself apparently after about
an hour.
On Friday, January 31, 2014 4:00:23 AM UTC+2, David Ward wrote:
>
> My app id: versature-integrate
>
> On Thursday, January 30, 2014 8:43:44 PM UTC-5, David Ward wrote:
>>
>> I am experiencing the same issues r
My app id: versature-integrate
On Thursday, January 30, 2014 8:43:44 PM UTC-5, David Ward wrote:
>
> I am experiencing the same issues right now. Did you find anything out?
>
> On Monday, January 27, 2014 11:59:13 AM UTC-5, Lucian Baciu wrote:
>>
>> Hi,
>>
>> My app just starting experiencing an
I am experiencing the same issues right now. Did you find anything out?
On Monday, January 27, 2014 11:59:13 AM UTC-5, Lucian Baciu wrote:
>
> Hi,
>
> My app just starting experiencing an issue a few hours ago. All
> add/updates/delete operations on an entity "History" are executed
> successful
On Monday, July 9, 2012 4:28:30 PM UTC+2, pdknsk wrote:
>
> I don't know if it's documented, but it was mentioned in the release
> notes.
>
> The Datastore API now includes a NonTransactional decorator to ensure
> that a function is run outside of a transaction. Existing transactions
> are paus
I don't know if it's documented, but it was mentioned in the release
notes.
The Datastore API now includes a NonTransactional decorator to ensure
that a function is run outside of a transaction. Existing transactions
are paused while the function is executing.
--
You received this message becaus
For the benefit of anyone coming to read this thread years later, GAE 1.5.5
will be supporting cross group transactions:
https://groups.google.com/d/msg/google-appengine/f9YVplAlRs4/xFnah8fGTNMJ
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" gro
Thanks Jeff, I'll just try the switch at a later time and see how it
goes. I'm pretty much managing the namespaces already in the code so I
think that shouldn't change much, and it's all server side.
Hugo
On Sun, Jul 24, 2011 at 10:06 PM, Jeff Schnitzer wrote:
> I can't really tell whether the K
I can't really tell whether the Key change would be an issue for you - it
would depend a lot on how you are using namespaces and how you generate keys
(remote java client? gwt? server-side only?). If you're using the
"standard" practice of setting namespace *immediately* in a servlet Filter,
you
Correct, I'm still on 2.2.3 (it's great, thanks!). Would I run into
big problems switching to 3.0 because of this? In only one or two
instances I ran into the last minute key conversion issue, but I've
worked around that with a ObjectifyWrapper which is actually not bad
at all. In the spirit of "if
If you are using Objectify 3.0, the Key is a simple wrapper for the
native datastore Key - with all the same namespace consequences. In
previous versions, the Key -> Key conversion was done last-minute so it
would "inherit" the namespace then.
Jeff
On Sat, Jul 23, 2011 at 5:51 AM, Hugo Visser w
Well it appears that the entire key path for an entity group is bound
to one namespace. I am using Objectify in my app which doesn't have
the namespace in the keys but when checking out the low level Java api
that became apparent.
On 22 jul, 12:48, Hugo Visser wrote:
> Is it anywhere explicitly d
I think Nick told this group that if you have to update the object 1
or 2 times per second there is no need to use sharded counters.
It just depends on how rapidly it is for your object.
I think you missed what sharding is about.
If your application needs to update a counter object many times a
s
Hi Jerry,
You should use transactions any time you're doing a read-modify-write cycle
that could be happening concurrently - eg, it could be modified concurrently
by more than one user.
-Nick Johnson
On Wed, Oct 7, 2009 at 1:47 PM, jerry ramphisa wrote:
>
> Hi
> I have three sets of tables. Now
Hi Cornel,
I recall a session at Google I/O from Daniel Wilkerson which describes this
scenario and an approach for solving it:
http://code.google.com/events/io/sessions/DesignDistributedTransactionLayerAppEngine.html
The above describes an implementation which does not require A and B to be
in
Hi Cornel,
Atomic transfers between accounts is a classic example of a 'hard'
scalability problem. It's being tackled on App Engine, however, with
higher-level transaction libraries. There were a couple of talks about
it at I/O this year:
http://code.google.com/events/io/sessions/DesignDistribute
I think this problem is discussed there:
http://code.google.com/p/googleappengine/issues/detail?id=313
Julian
On Aug 7, 4:30 am, Cornel wrote:
> Hello. I'm using app engine to write a business application. I've read
> that during a transaction one can modify only entities within the same
> en
Hello
I don't think my message got on the group:
On Thu, Aug 6, 2009 at 10:30 PM, Cornel wrote:
> Hello. I'm using app engine to write a business application. I've read
> that during a transaction one can modify only entities within the same
> entity group. How would one approach the following
On Jul 13, 5:43 pm, Bill wrote:
> The reason sharding works to reduce contention is that the each shard
> is in a separate entity group. Within the transaction, one
> GeneralCounterShard entity is either retrieved or written. Each shard
> forms its own entity group, which is what you want so th
The reason sharding works to reduce contention is that the each shard
is in a separate entity group. Within the transaction, one
GeneralCounterShard entity is either retrieved or written. Each shard
forms its own entity group, which is what you want so there's no
contention on writes.
On Jul 13
Yes, agree. That is the right solution for deletion. Thank you.
But what about creation of a new Game? How can I guarantee that the
team1 and team2 are valid (still in the datastore) when I create a new
Game?
On Apr 13, 2:40 am, djidjadji wrote:
> If a Team has a lot of Games you don't have
If a Team has a lot of Games you don't have enough time to delete them
all in 30 seconds.
You must use a method that always work, even in the event that the
datastore is giving troubles or is in maintenance (no write or delete
possible).
What you could do is mark the Team as being deleted, add a
Ok maybe I don't absolutely need it to delete a team but what about...
1) when I'm creating a new game - team1 or team2 could be deleted as
I'm creating a new game, then the game will have a team that does not
exist
OR
2) for arguments sake, I need the deletion of a team (and all the
games it's
Start with answering the question: Do I need a transaction?
I don't think you need it to delete a team.
Every Team and every Game are root entities, no child objects.
When you want to delete a Team
1) find all Games that have the Team in attribute team1
2) delete these Games, maybe delete
24 matches
Mail list logo
