We Keep Coding

What is best practice for objectify transaction handling for a request

I have a GAE app with a JSON REST API. For each entity I have a DAO class with the objectify code, and a service using the DAO. The service is responsible for the business logic related to the entity. Some calls to the API are expected to use logic across the services, i.e. calling methods in several services.
I would like each call to the API to be one transaction, i.e. either all datastore operations succeeds and are persisted, or if an exception occurs all datastore operations fails and none of them are persisted.
I can see that if I do two separate ofy().transact(...) and throw an exception in between, then the operation of the first ofy.transact() is persisted, but not the second. If I do one ofy().transact() and inside this do one datastore operation, then throw an exception and do a second datastore operation, none of the operations are persisted.
From this I assume that rollback only happens if the exception is thrown inside the ofy().transact().
My question is:
If I have a API call which works across services, I need to encapsulated the calls to the services in an ofy().transact in order to ensure rollback if an exception occurs?
I would like to have kept all my use of objectify in the DAO classes, so an alternative solution would be great.
Thanks,
-Louise

Transactions are a cross-cutting concern - basically a bit of thread local state. When you start a transaction, it follows the thread until the transaction completes (no matter how many times you nest calls to transact()).
If you don't want Objectify-specific classes referenced across your codebase, just make your own wrapper for transact(). Transactional unit of work is a broad database concept.
However, keep in mind that transactions in the datastore are somewhat limited and you can't just apply "start a transaction" everywhere the way you typically would with an RDBMS.

Implementing Java DAO Pattern on the Same JVM

This question is related to the core understanding of the Java DAO Pattern. Please look at a simple java dao pattern example to understand my question.
At line 2 below, the student object has already been altered with a new name, what is the point of line three if both the client and the backend are running under the same JVM?
In my humble understanding of the DAO pattern, the client must only alter data using services, such as the studentDao below, and the client shouldn't have the possibility of altering the value object (pojo) directly. But when both the client and the backend service run under the same JVM, and client gets a POJO with normal setters, why does the client need to call the service?
Are there any best practices to implement a DAO pattern where the client can and must only consume/alter data using dao-services? A very example would be great to look at.
//update student
1. Student student =studentDao.getAllStudents().get(0);
2. student.setName("Michael");
3. studentDao.updateStudent(student);

well, what does it mean on same JVM. If your DAO uses DB, then the object won't change in DB when you change POJO. Similarly, when other thread will load the same entity, the new POJO will be created based on the DB content (unless your DAO makes some special caching) => no problem.
So for now let's assume that you build some kind of in-memory DAO. If not implemented properly, in such case change on POJO can "effect" other clients as you have already pointed out. However this is not good implementation of DAO - so you have to take care that POJOs accessible by clients can't have impact DAO "state". The easiest way to do so is always return defensive copies for both all returned values but also for all inputs (insert, update etc).

Structuring a playframework application

I am new to playframework, so although this might be a newbie question, I need to ask. I have an application, where the database data can be changed by web requests, as well as by incoming emails.
I know that controllers are primarily used for web requests. Therefore, should I encapsulate the model modification logic in a separate class, which I should call from both the controller, and the guy who accepts the emails. Is this what the Service paradigm is used for?
Second, what should I use for the mail acceptor. A job or a plugin? Currently I created a job which refreshes itself every 10 seconds, but didn't know if it is appropriate to use a job to modify the DB. Perhaps, the job can trigger an internal event which a plugin will listen for ...

Yes you can update the model throught a job, job are transactionals.
For your common logic, if it relates to a specific model object, you can use a method on this object to put your common logic : put in static methods every code that is not tied to a specific instance and in non static methods logic that is tied to a specific instance.

why have manager files in JDBC

I'm playing around with JDBC, and I've noticed that there's usually a manager file that interacts between the front end and the DAO.
I was wondering: why is this the case?
Is it bad form to have the front end directly interact with the DAO and call the methods?

The question isn't very clear. If by "manager file" you mean "service", I think that's closer to the truth.
The reason is that usually there's more work to be done than a single DAO call to accomplish a use case, so a service marshals all the objects that are required.
If there are any write operations, it's typical that they either all need to succeed or fail together, so the service can own the transaction and manage the commit/rollback behavior.

Creating a Publish-Subscribe Pattern to integrate to the DAO pattern

Based on the question (How to create a client notification service for a webapp or should I use an Observer Pattern?) I will like to know.
I have a fully implemented DAO with Entity beans containing only getters and setters method. Each entity is mapped to an EntityManager.
Currently there are no way of notifying users of any changes added/deleted/updated to a persistent storage such as a database.
I want to know, how will I implement the Publish-Subscribe pattern (also known as Observer pattern) such that I don't have to extend my current DAO architecture. I don't want my entities to inherit the Publisher because not all entities are update-able.
If there are any tools/frameworks/libraries that I can use for my situation, please let me know. Also, I'm not using any persistent framework at all (framework such as Hibernate), the DAO manager and Factory was completely written from scratch by me.
Regards,

I am building a similar concept... I don't care about all events and within projects we want to care about different events. So, we are building a pattern where all DAO operations are submitted to DROOLS Fusion and based on rules and some temporal reasoning, it notifies listeners via a notification architecture. Depending on your needs, the architecture could be simple listeners or JMS or email... whatever. If you have no criteria, just care about a callback for DAO events, then have your DAO insert, update, delete operations submit the object to listeners or some type of JMS queue.
Hope that was clear...
Paul

The first suggestion I would have is to embed an observable object within your DAO. Then you would have your subs look at this object (I've done similar things in the past).
The other suggestion I have is that you could add a trigger to the database itself. This would be especially useful if there is anything outside of your app that could change the DB that you want to notify your sub of.
Good luck.