Hi Yegor, thanks for your suggestions.
But I yet cannot understand how to cope with transactions in the
scenario you have described.
Let's say that I have the following (usual) example:
public class User {
Long userID; //it is the PK of the object
ArrayList<Contact> contacts;
...
}
public class Contact {
Key contactID; PK of the object;
String email;
long friendID; //this is the ID of the user pointed by this contact;
0 if the contact points to an external user
...
}
So in the example we have two users: Alice (ID=1) and Bob (ID=2).
They have respectively the following contacts:
Alice: {Bob (friendID=2), [email protected] (friendID=0)}
Bob: {Alice (friendID=1)}
As you can see [email protected] is not yet a User of our app, so the
contact pointing to him has friendID = 0.
Let's say now that Caius becomes a User (ID=3).
I wish to change the contact of Alice adding such information,
becoming the list of Alice: {Bob (friendID=2), Caius (friendID=3)}.
Such a task should be done in a transaction, checking all the friends
having e.g. the email [email protected] and setting their friendID to 3.
But the Contact objects with such email belongs to several Users and
possibily to several entity groups.
Moreover, I cannot split this task in different subtasks if I don't
want to loose the integrity of the data.
So what's the solution for this issue in your opinion?
Sorry for the long example but with the usual toys of the tutorials
these issues are never addressed!
Waiting for your response
Thank you very much.
Bye
CRI
On Dec 30 2010, 6:01 pm, Yegor <[email protected]> wrote:
> > I had to strongly synchronize my app using Java options (locka,
> > synchrnized objects, and so on...).
>
> I have to warn you that all this synchronization will be in vain once
> your application grows beyond 1 JVM. Java keyword "synchronized" is
> only effective within a single instance of JVM. That is not to say
> that even with 1 JVM your application may lose a lot of performance if
> you are synchronizing on static methods or singleton objects, e.g. the
> datastore.
>
> > I think it is quite unbelievable that a huge giant like BigTable is so
> > weak in concurrency issues...
>
> BigTable gives you a lot of well-documented options to deal with
> simultaneous access to data. A good place to start
> ishttp://code.google.com/appengine/docs/java/datastore/transactions.html.
> In your case, unless you really have to transact on all entities
> processed by the servlet, I would recommend that you break your task
> into several sub-tasks each limited to a single entity group.
>
> > Perhaps my approach is geared from my experience in relational DBs,
> > but I'm quite puzzeld...
>
> Sounds like that might be the case. When working with BigTable, always
> keep in mind that two entities (called table rows in RDBMS) do not
> necessarily end up on the same server node. This is good, because it
> allows BigTable to distribute the load across multiple hard drives.
> However, when this happens you no longer are able to transact on these
> entities. Entity groups tell BigTable that two or more related
> entities must be stored in the database in such a way that a
> transaction is possible. Unfortunately, you immediately lose
> scalability within the entity group (thus the recommendation to keep
> them small). Relational DBs always make that sacrifice by default and
> put all table rows on the same hard drive. This makes it easy to
> transact on arbitrary entities. However, you have to partition your
> database manually to scale. Plus, you cannot transact across
> partitions, so even with a RDBMS you still have the same limitation.
--
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 [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-java?hl=en.
