:)))
following the recent "standard configuration of jboss" mail, and as I work
on the complexPK rewiring problem for O(1) operation I realize that there
are ways to shoot yourself in the foot with these.
The Tx Option right now, if not specified in the xml file is that we return
"supports" for the transaction attribute, again unless specified. I propose
to change that to "required" for the simple reason that at least it will
mean that folks will get their data persisted at the end of each call. (ie
as 90% cases will be).
I believe (and I did it :() that some times if you forget to specify the
TxAttribute (you need to understand what they mean before you can set it
properly) then you don't see the persisted stuff. That is dangerous since
most folks know the DB world and will go look at the tables to see if the
stuff was persisted and will say "huh... jboss did not persist my data
wtf"... I would rather address mails that say "how do I disable the
storage?" than mails that say "how come the storage did not work?"
I would set the standard behaviour of jboss to store the stuff, always,
ejbStore() called.
I would also set (and that is the way it is right now) the commit option to
A so that we don't load.
Of course if someone understand the semantics of "supports" vs "required"
then they can safely say "supports" in the ejb-jar.xml and we will behave
according to spec... which it already does.
Also if someone understand the A,B, C commit options (jboss is not unique
access to DB) then you can specify B or C in the jboss.xml advanced
configurations.
So standard is:
1- TxRequired if nothing is specified
2- Option A if nothing is specified
The DTDs and examples are coming...
comments?
marc
________________________
Marc Fleury
Chief Technology Officer
Telkel, Inc.
________________________
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
