I'm porting an existing application RESTful API to a Java web framework -- I don't actually care which -- but it's proving hard to get the basics right.

The core of the problem appears to be getting the bridge between JAX-RS and the database so that transactions work. The API uses subresources a lot, and the way JAX-RS appears to work involves returning a new locator. Now that's a nice pattern, but it means there is nowhere that makes an effective bound on the transaction, so the @Transactional annotations become a problem. I'd really like them to be scoped to the request somehow, but none of the frameworks I've tried seem to make that easy, or even possible.

It's a kind of a three body problem. I can do transactions and queries fine by pushing them into a repository layer, but then I'd have to not use subresources. Or I can do subresources and even queries nicely but then there is nowhere nice for the transactions to happen. Basically I can have any two of transactions, subresources, and complex queries, but I need all three.

So far, I've tried to get this working with Guice + Jersey + Querydsl, and with Spring Data and Spring REST. They all seem entirely based on the idea that each endpoint can be @Transactional, and (usually) that it is a simple CRUD API on tables. I have a very nice front end already built. and I can't see any good reason to totally rewrite it because Java makes the services awkward to build.

I know somehow I need to get the transactions tied to the request, and use DTOs anyway so I'm happy with that, but I can't find any way to make that happen. Does anybody have any useful pointers, templates, advice?

  • Is JAX-RS required?
    – scriptin
    Commented Feb 20, 2015 at 21:46
  • Probably not, now I think on it. Although there's a lot of access from parent to child resources, so it would be good to keep the ability to chain data through the path. Commented Feb 21, 2015 at 2:48
  • I don't understand, why can't you tie your Transaction to the root resources? Commented Feb 21, 2015 at 7:27
  • Because then the transaction ends when the root resource method ends. However, that method returns a locator (essentially an instance) for the subresource, and starts navigating that. Of course, then the root method transaction has already been committed and we're therefore not necessarily consistent. Commented Feb 25, 2015 at 14:58

1 Answer 1


If JAX-RS is not a requirement, then I'd suggest looking at Restlet. It uses conveyor architecture, so nesting resources into other resources is not a problem - see hierarchical URIs. When integrating with Spring, you typically define root SpringBeanRouter, in which you put actual resources, in each of which you can put another routers, and so on.

You can wrap every method of every resource by just defining top-level request filter, which could use Spring's transaction template or something similar. Or, since you're not required to return locators, you can just go with @Transactional annotation on methods of (sub)resources.

See org.restlet.ext.spring package for details.

  • This looks like a nice solution. I'm porting an Express app, and this is very much closer to the Express router architecture. That app did use a transaction per request, more or less, so the filter is probably better. I'm also preferring Guice to Spring, but Restlet seems to support that very nicely. I'll have a quick dip to try it, but this looks a great solution. (I'll accept when I've got a bit further on it, to be safe). Commented Feb 25, 2015 at 15:05
  • And having played with it -- using Spring for now as it was easier to get started -- this definitely seems a great way forward. At a meta-level, this would seem to be a big flaw in JAX-RS, and one I'm not the first to have come up against. Although the Restlet documentation is joyously wonderful compared to that of Spring, and I'd probably now make it work with JAX-RS if I wanted. I don't want: Restlet seems much better for my purposes. Commented Feb 25, 2015 at 22:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.