Java Persistence API (JPA) implementation for Amazon SimpleDB

Home

News: Java Persistence API (JPA) implementation for Amazon SimpleDB

  1. I've spent some time attempting to create a JPA implementation for SimpleDB to see if it could be done and because I couldn't imagine working without my object relational mapping framework - and yet SimpleDB is compelling. [Editor's note: SimpleDB is "web service for running queries on structured data in real time." It's also marked as a public beta, so don't go in thinking it's something it's not.] After some serious hack sessions, I've got what appears to be a solid working version, albeit it is a subset of the full JPA spec due to the nature of SimpleDB vs RDBMS. It currently supports:
    • @ManyToOne - object references.
    • @OneToMany - collections.
    • @MappedSuperClass - Useful for a common ID and timestamping class.
    • @Inheritance
    • @Lob - stores lobs in S3 so make it as big as you want (up to 5GB).
    • @Id - Assigns UUID automatically
    • Lazy loading on ManyToOne, Lobs, and OneToMany so only hits SDB on an as needed basis.
    • Rudimentary caching to reduce hits on SDB
    • JPA Queries
    I would love any feedback and if anyone is interesting in helping out with the project, let me know.

    Threaded Messages (23)

  2. with no more worrying about uptime
    Amazon Web Services goes down, takes out some Web 2.0 sites
  3. with no more worrying about uptime
    Amazon Web Services goes down, takes out some Web 2.0 sites
    Note the "public beta" aspect...
  4. Note the "public beta" aspect...
    As I understand it, all AWS went down, not just beta implementations. This kind of thing is interesting and exciting but lets try to avoid overselling things. If you think that trying your system to Amazon will mean you don't have to worry about it going down, you are in denial. I'm just a little sick of people making these kinds of unsubstantiated claims and no one calling them on it. I have to argue with non-technical people all the time about why hosted solutions don't solve all your problems and why they actually create some new ones. Press releases that appear to validate these pipe-dreams are not helping.
  5. As I understand it, just S3 went down. In any event, what do you care so long as they honor their SLAs (which currently guarantee three nines)?
  6. As I understand it, just S3 went down.

    In any event, what do you care so long as they honor their SLAs (which currently guarantee three nines)?
    That's fine if 3 nines is good enough. For a lot of systems it is not. 3 nines and 'no worries about uptime' are not the same thing at all.
  7. My point is that if you agree to their terms, then by definition, it means there are "no worries" otherwise you wouldn't have opted to use their services in the first place (unless you're insane). There actually are sites where 3 nines is sufficient.
  8. My point is that if you agree to their terms, then by definition, it means there are "no worries" otherwise you wouldn't have opted to use their services in the first place (unless you're insane). There actually are sites where 3 nines is sufficient.
    First of all, what period of time are you using to calculate your percentage or uptime? Over a year? For a year 3 nines is less than 6 hours downtime. They were down for a third of that in a single day. In fact, the SLA for S3 specifies that 99.9% uptime for a 5 minute period. So in fact they did not achieve that uptime on that day and apparently owe some credits. It's also worth considering that a full outage only gets a 25% credit. http://www.amazon.com/b?ie=UTF8&node=379654011
  9. That's fine if 3 nines is good enough. For a lot of systems it is not. 3 nines and 'no worries about uptime' are not the same thing at all.
    But for a lot of systems it is ;-) For example, we at GridGain will be migrating all our Continuous Integration JUnit test suites to run on EC2 shortly. EC2 does translate into big savings for us and for many other organizations. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  10. That's fine if 3 nines is good enough. For a lot of systems it is not. 3 nines and 'no worries about uptime' are not the same thing at all.
    But for a lot of systems it is ;-)

    For example, we at GridGain will be migrating all our Continuous Integration JUnit test suites to run on EC2 shortly. EC2 does translate into big savings for us and for many other organizations.
    Great, thanks for the info. I'm getting a haircut next month.
  11. I get the sarcasm :) What I meant to say is that there are by far more use cases for EC2 where 3 nines ratio for uptime are way more than enough. (Let me know how that haircut goes) Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  12. I get the sarcasm :)

    What I meant to say is that there are by far more use cases for EC2 where 3 nines ratio for uptime are way more than enough.

    (Let me know how that haircut goes)

    Best,
    Dmitriy Setrakyan
    GridGain - Grid Computing Made Simple
    Sorry, that was a little rude. My only excuse is that I've got a sinus headache coming on. I am not saying that Amazon services are bad or that you shouldn't use them. I might want to use them at some point. All I am saying that hosted services, like any other solution have pros and cons and limitations. All I am asking is that we have a rational discussion about reality. Is that really too much to ask?
  13. What I meant to say is that there are by far more use cases for EC2 where 3 nines ratio for uptime are way more than enough.
    One more thing. As I note above, S3 did not achieve their three nines (as defined by their SLA) a little over a week ago. It may be the case that this will never happen again. But the fact remains that it did just happen. If I'm not mistaken, your continuous integration solution is not mission critical and a 3 hour outage should be mainly an inconvenience.
  14. If I'm not mistaken, your continuous integration solution is not mission critical and a 3 hour outage should be mainly an inconvenience.
    Right. If you have production uptime requirement that does not fit into 3 nines uptime ratio, then EC2 is definitely not for you. EC2 has plenty of limitations (such as database for example), however, I do believe that there is a good number of enterprises that will have (or already do have) a number of use cases for EC2. It's not a silver bullet - use it when it fits. Best, Dmitriy Setrakyan GridGain - Grid Computing Made Simple
  15. I really didn't want to get involved in this flame discussion, but just had to say a few words. 1) That's the first time in two years they've had a major outage from what I can see (3 hours in two years, not bad) and it was only on S3. Can you make that claim on your own servers/databases that you are managing? (maybe you can, but i'm sure it's kept you up at night). 2) When it goes down, you don't have to fix it. 3) It's more than just about the uptime. You don't have to worry about backups, redundancy, storage, etc. That being said, it's clearly not for everybody.
  16. I really didn't want to get involved in this flame discussion,
    Calling it a 'flame discussion' is a great way to subtly imply that it's not a valid discussion. The first of a number of rhetorical techniques in your response.
    but just had to say a few words.

    1) That's the first time in two years they've had a major outage from what I can see (3 hours in two years, not bad) and
    It's not terrible in terms of averages. However, averages are not really the most useful statistic and often the most misleading. My car has been very reliable over the 8 or so years I've owned it. But if I end up stranded somewhere because it's not working now, knowing that it's reliability has been over 99.9% isn't very comforting. If the outages were well spread out the two years I would agree that it's pretty good. Not five nines good but OK. But it was around 3 hours of continuous outage. That's not very good.
    it was only on S3.
    Is your contention that S3 is less reliable or less supported than other Amazon hosted services?
    Can you make that claim on your own servers/databases that you are managing? (maybe you can, but i'm sure it's kept you up at night).
    I don't know if it's me or the medium of discussion but I don't understand why you (and so many other people) expect me to defend something I never claimed and is completely irrelevant to the subject at hand. The article intro says 'no worries about uptime'. I think that's a pretty misleading statement.
    2) When it goes down, you don't have to fix it.
    Nor can I. That's the downside that people overlook. If the 3rd party can resolve their issue quickly it's great but if they are not able to do so, it becomes a big problem.
    3) It's more than just about the uptime. You don't have to worry about backups, redundancy, storage, etc.

    That being said, it's clearly not for everybody.
    Of course I was only talking about the 'no worries about uptime' statement so none of this is relevant.
  17. more[ Go to top ]

    more info ------------------------------------ http://www.matlabtutorials.com/ Matlab tutorials
  18. I would love any feedback and if anyone is interesting in helping out with the project, let me know.
    Hi Travis, we'd be interested in having support for SimpleDB as a plugin for JPOX. This would mean that support for JPA XML/annotations would be complete (other than where SimpleDB is itself lacking), and you would automatically gain a JDO interface for the same datastore, some JPA extensions, as well as L1/L2 caching, and much more. If this is a direction you'd like to take it, contact us offline. If not then good luck with your project. --Andy Java Persistent Objects (JPOX)
  19. I find it very interesting that you got a JPA implementation working against SimpleDB. Not having a good persistence option has kept me away from considering S3. Maybe this will change my mind. Can you give us any feedback on your experiences with respect to SimipleDB's performance, when using your JPA provider? Thanks,
  20. Source Code?[ Go to top ]

    Hello, I went to the project site on google and checked out the trunk but there's nothing there. Neither is there anything in the tags nor branches. Are you going to make the source available? Thanks, Ted
  21. Source code is now available[ Go to top ]

    Just put it up tonight: http://code.google.com/p/simplejpa/
  22. Nice job![ Go to top ]

    It's great to see someone from the Java community take initiative and design something from scratch like this that could be potentially useful to a lot of folks. I will definitely be checking it out.
  23. Re: Nice job![ Go to top ]

    It's great to see someone from the Java community take initiative and design something from scratch like this that could be potentially useful to a lot of folks. I will definitely be checking it out.
    BTW, I am currently helping a Terracotta user who has built a SQL database manager AMI that runs in EC2 that fronts SimpleDB. The SQL interface stores its mappings and "fixes" SimpleDB's 1-second latency using a Terracotta Server in the middle. Should be available in open source at www.terracotta.org shortly. Stay tuned. --Ari
  24. Yes, indeed, good idea, but Amazon SimpleDB beta is closed and no source with SimpleDB.