Enterprise Erlang Beams?

Vlad Dumitrescu vlad_dumitrescu@REDACTED
Mon Nov 3 11:58:01 CET 2003

From: "Mikael Karlsson" <mikael.karlsson@REDACTED>
> I had a some kind of analogy in mind, but the idea is quite vague. What I like
> about EJB containers is the transaction support that means that you should
> not need to worry about the transaction yourself. It comes "for free" in some
> kind of declarative manner.
> Leaving out all the problems with security, for the moment, the analogy would
> be to spawn off a gen_server  (or gen_fsm for a stateful session bean?) as a
> worker thread within a transaction. Parts of the contents of the server State
> could map to the persistent store and be used at commit/fallback time,
> without the gen_server explicitly taking part in the transaction.
> One could maybe even have some kind of persistent behaviour were the
> gen_server is spawned with a state that is restored from the database. (It
> could be spawned on another node as well.)

Oh, you meant like that... Yes, it's a cool idea. I'm not sure what would be the
best way to do something like this "the Erlang way", but I feel it deserves some
more thought.

What is needed at first sight is a way to automatically apply transactional
semantics to each call to this process.

On the other hand, having semantics described in other place than the source
code is not really very much fun. I find it difficult to keep track of every
detail, when there are 4-5 files describing what one single bean does, sometimes
whith very subtle dependencies...

Adding some syntactic sugar to define transactional properties wolud add to the
language, something not very popular these days :-)


More information about the erlang-questions mailing list