Sign in to follow this  

[java] EJB programming restrictions..

This topic is 4763 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi guys This isn't directly game related (apologies). I'm writing some Java threading guidelines with a colleague and, since most of our code runs in an EJB container, an important section relates to the (threading) restrictions placed on EJB programming. Specifically: - non thread management - no synchronisation - no non-final statics I understand the reasoning behind these and I'm pushing to include them in our guidelines. However there is always the (nonsensical to me) argument that the EJB restrictions only apply to the EJB code itself and not any classes deployed with and used by it (in many cases the majority of the EJB's implementation - in our case ALL of it). A supporting argument to this is that the JDK itself breaks all of these restrictions - but must by definition be used in an EJB's implementation. Although the JDK argument is a tough one to counter - I believe it comes down to the JDK and Container being implemented by the same vendor - the vendor knows their implementations and therefore will have addressed any issues. We don't and shouldn't know their implementation so should stick to the restrictions. Not ideal - but sometimes you have to accept things like this. So - any thoughts on this? I've searched for a definitive answer on this - but would be interested in any links people have too. cheers Stubble

Share this post


Link to post
Share on other sites
Quote:
Original post by stubble- non thread management

The container creates and manages a pool of threads. This pool may grow or shrink at any time and out of your control. If you create your own threads, you may cause an out of memory error by having too many threads in existence, because the container cannot account for your threads. The VM on the other hand has a fixed number of known threads.
Quote:
Original post by stubble- no synchronisation

Don't know.
Quote:
Original post by stubble- no non-final statics

This relates to different users will be served by different instances of the same servlet. If you use statics, they can clobber each other. Since final statics are immutable, they cannot be changed, so there is no danger.

Share this post


Link to post
Share on other sites
Incidentally, this is why we gave up on J2EE as entirely useless for games development 4 years ago. You have so little control over the environment, and so many restrictions; where this may be bearable for simplistic business logic it's intolerable for high-performance systems like MMOG's :(.

Share this post


Link to post
Share on other sites
cheers guys - as I said I understand why each restrictions applies and how to justify each one in an EJB - but I was having problems convincing my peers that they apply to classes deployed with and used by the EJB too.

My main problem was finding somewhere that said "the restrictions apply to classes used by the EJB too" - the spec seems to miss this important clarification which some people use as a reason to ignore the restrictions by putting all their logic in a POJO and calling it from the EJB. This makes no sense to me - but I needed to justify it to my colleagues.

If anyone is interested I found something which says what I wanted:

http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html

thanks

Share this post


Link to post
Share on other sites
Quote:
Original post by redmilamber
Incidentally, this is why we gave up on J2EE as entirely useless for games development 4 years ago. You have so little control over the environment, and so many restrictions; where this may be bearable for simplistic business logic it's intolerable for high-performance systems like MMOG's :(.


And so, what type of architecture did you propose for such games in the past? And what do you propose now? :)

Share this post


Link to post
Share on other sites
Quote:
Original post by CaptainJester
This relates to different users will be served by different instances of the same servlet. If you use statics, they can clobber each other. Since final statics are immutable, they cannot be changed, so there is no danger.


Not to be pedantic, but some people forget that "final static X = new Y()" means that the reference X will always points to Y, but not that Y cannot be changed. You can only guarentee this if Y is immutable.

Share this post


Link to post
Share on other sites
Quote:
Original post by seanw
Not to be pedantic, but some people forget that "final static X = new Y()" means that the reference X will always points to Y, but not that Y cannot be changed. You can only guarentee this if Y is immutable.


Too true.

Quote:
Original post by stubble
My main problem was finding somewhere that said "the restrictions apply to classes used by the EJB too" - the spec seems to miss this important clarification which some people use as a reason to ignore the restrictions by putting all their logic in a POJO and calling it from the EJB. This makes no sense to me - but I needed to justify it to my colleagues.

They apply to all classes because all classes run within the server's container. Not just servlets and EJBs. Therefore the container resource pool is affected by every class that you run.

Share this post


Link to post
Share on other sites

This topic is 4763 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this