I completely understand what you're looking for and I don't say that there
is no ways, or patterns to do this, but considering the example, most of
the time it is better just to let the system  live up, without any condense
control. this way, some people might get the error message "sorry, class
is full now" after they submit a request (even after initial checks that
let them enter the form for this request), but this makes system so
simple. Database is transactional, and any time you wanna add a new entry,
just check to see if thing are still OK or not.

Most of operation systems, databases, etc are like this. Its so nice just
to prevent any thing wrong (e.g. dead locks) to happen, but in 90% cases
the cost you pay to do all these checks is more than what you get. There
are cases system should be pessimistic, but the example below can be
considered no to be one of them

According the EJB spec states, you can not use synchronized keyword or static fields in EJBs but you can call to the classes that does use them, you never know what is the difference while container is the one managing this for you, so the solution would be simple but tricky.

As Amin is saying, you might end up saving data to be contained out of your EJBs and keep them in data source. this means that a session bean can implement SessionSynchronization interface to perform run a check before and after any transaction to this data source; assuming you have already set the proper transaction attribute to perform a lock/unlock on the resource (which could be a table of your classes according to your example). Your session bean can be the one performing the query to the table and returning a result which indicate availability of free space in the class.

Aside from that, an interesting discussion that I've seen somewhere else is the use of GoF singleton within EJBs i.e. something like the way a local service locator is implemented with in a cluster. sounds a bit strange for the EJB to call out to a singleton but doable. but one note that you can not used it for read and write as it may block threads created by container on EJBs.
If you want to use the singleton approach, read chapter 11 of Mastering EJB 3rd Ed, (Writing Singletons in EJB). That would be very helpful specially if you have more than one cluster.

This is exactly what I am looking for, alternative methods to what is
said in chapter 11 of mastering ejb  3'rd edition.
As you may know .net 1.0 has a very good solution (special kind of
com+ components) for this purpose.

I am sure that there should be a scalable solution which works fine in
a cluster of servers.

If transactions are handled by EJB container why synchronization  is
not handled by container? (Like in .Net)

by answers I guess most of java developers are ignoring this important
aspect of software!

Use hibernate and ejb  by each other, and put the following tag in ur cfg.xml

  <property name="hibernate.transaction.manager_lookup_class">net.sf.hibernate.transaction.OrionTransactionManagerLookup</property>
      <property name="hibernate.transaction.factory_class">net.sf.hibernate.transaction.JTATransactionFactory</property>

> What pattern  are you using for synchronization  in middle  tier?

What do you mean by this? Are you going to deploy your application on a cluster
of application
servers and trying to keep all your nodes in-sync? Or are you caching your
entities and need to
keep your cache and backend RDBMS in-sync?

> There is a class  registration system, every class has a limited
> capacity, system  should not register students in any class more than
> its capacity. We want to handle  this in middle tier  (EJB).

I'm still not sure what are you asking for but you can simply use a stateless
session bean for
this. Sure the client might access the SLSB via a Session Facade or a Business
Delegate but this
check for capacity is better not be done in one of your Entity Beans' setters,
etc.

There's no infinitely scalable solution to this problem. There are many
"good-enough" solutions though. I don't know what .Net does, but it
must be
one of those good enough solutions for a range of problems.

Speaking of your program ("every class  has a limited capacity, system
should
not register students in any class more than its capacity"):

The simplest solution is to assume no one else registers the last seat
of
the class while you are also doing that. Well, in many systems the load
is
not that much anyways, and this solution works there.

Another simple solution is to use "serialized read/write" for
reading/writing the rows for this busy table. So basically no one else
can
touch the rows of that table while you're working with it. It puts a
lot of
load on the db of course.

A solution that I like most is to use a good clustered cache. Take a
look at
this: www.tangosol.net/.../thread.jspa
Basically you put a token in the cluster and that token is replicated
to the
other nodes. While there's this token, no other node messes with your
data
:) I've read somewhere that a company called Terracotta provides
essentially
something like this but transparently by intercepting synchronized()
keyword
and injecting some clustered cache byte code there! Very pretty
solution!

But of course even this clever solution is not the ultimate answer. In
a big
cluster, replicating all these little token objects can saturate the
whole
network :)

Tell me: how does google's indexer engine makes sure it doesn't
incorrectly
index a site twice? Is there a hashtable somewhere in memory? You see
they
have 100s of 1000s of servers. You can't really cluster such a thing.
Google
tries to partition its data cleverly, and it works with the big cluster
by
starting big parallel processes (based on MapReduce technique:
http://labs.google.com/papers/mapreduce.html).

As i understood, you need a notification mechanism which can notify "registration system" (and even students) about classroom object changes. I'm not sure but, the Observer Pattern(Publisher-Subscriber) would be usefull in this situation. Classroom object is your subject(entity) and "registration system" and students are your observers.

I should say I disagree

observer pattern  is not a messaging technique while publish-subscriber is a messaging technique.

I understand what you are trying to achive but this is not the correct direction. observer in simple terms is used for callback, but not for messaging. in observer pattern, subjects call out / notify observers (more like a method call), and there is no implementation / concept of queuing in this pattern.

you shouldn't confuse GoF observer with enterprise messaging.

now apart from messaging and observer discussion, consider the scenario below

client1 asks for a session to register in class  A
client2 asks for a session to register in class A

note that only one place is available

both are in the middle  of the session and both trigger a registeration request for the class A? what will you gain here from messaging? you can't stop them from registeration unless you have a logic with the data source to protect the data from exceeding a certain threshold.

This needs a protection over the common resource (class). one technique could be the use of transation and its proper attibutes (refer to transaction documents)

the other could be a singleton object per cluster (only a raw idea for the moment)

As long as I know there are generally two methods of synchronization
in distributed environments:
1- Shared memory
2- Messaging
The first method is usually faster in small clusters, but it has a two
disadvantages you can't have benefits of clustering failover, in large
number of servers this shared memory becomes the bottleneck.
Second methods is usually slower but if implemented correctly it may
enable you to have a cluster of equal servers with fail over benefits,
and the performance is not dropping much by increase in number of servers.
I want to know what method is every one using and compare odds and
even of those methods in an article, but it looks like except few
developers must of them are totally ignoring the synchronization  issue!
I want to ask EJB 3.0 spec members to clarify synchronization
mechanism of j2ee.
Do you have any suggestions on this?

This is not synchronization. You are talking about data propagation or data sharing

Re Shared memory: How do you "synchronize" access to the shared memory? here you need a "synchronization" method.

Re Messaging: If you modify your data and notify other components (possibly locally in other clusters) you might think that now everybody have the same data. Now consider that one of the receivers update the data and that should also notify others and so on. This way all the components within your system  will spend all the time notifying each other.

If you choose messaging you have two choices

1. to wrap the data and pass it along. So if someone updates it, it has to notify others again and so on
2. persist data in data source and then notify others to pick up the latest data. which again the above happens.

here are a few articles that you might find handy

www.javaworld.com/.../jw-0912-ejb_p.html
www.javaworld.com/.../jw-0223-extremescale_p.html
trailblazer.demo.jboss.com/.../index.html

apart from these, I think the best way to synchronize data access in such framework is the use of transactional syncrhonization. another method which is used within entity beans is by the use of ejbLoad and ejbStore which are called during lifetime of entity beans upon moving from state to state. and the other is by implementing SessionSynchronization interface.

initially I thought your intention is to synchronize access to the shares data (wherever it is), but now I might be confused as you are talking merely about sharing data and data propagation. am I correct?