An EJB solution may be an overkill, unless u're using the other services. U
could use a servlet/jsp engine that does the same thing much faster. My 2c.
----- Original Message -----
From: "fractals" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 04, 2001 6:51 AM
Subject: Re: [JBoss-user] help needed: transaction options for a simple case
> Hi again Dan,
>
> And thanks so much for your patience !
>
> Well, this is a neat solution indeed. The fact is, I've never used
> transactions so I don't know what they cost. At the very moment, I am
> beginning an implementation using JTA. To begin with, let's say that I'll
> probably abandon this idea in favor to yours. But I'd just want to expose
it
> for the sake of completeness:
>
> First off, I plan to use a centralized session management system, so I
don't
> have to be concerned by the http server providing the web interface, i.e.
> there could be many http servers running servlets that access my
> application. To do this, I have a Stateful Session Bean I call a
> UserSession, which is accessed by the servlets via a Stateless Session
Bean
> I call a Gatekeeper. Gatekeeper has a static Thread with a static
Hashtable
> field which holds the current active sessions. The thread part is used to
> periodically check the time-to-live fields of the UserSessions, and
> decrement them appropriately (and, again, I don't know if this is really
> needed). By the time I was waiting to an answer to my last question, I had
> defined the following methods to the remote interface of UserSession:
>
> public int checkPinCode ( String pinCode ) throws RemoteException;
> public boolean checkPseudo ( String pseudo ) throws RemoteException;
> public boolean setPassword ( String password ) throws RemoteException;
> public void setAnnouncePrefs ( int flags ) throws RemoteException;
> public void setUserData ( String data ) throws RemoteException;
> public void finishRegistration () throws RemoteException;
>
> As I stated in my question, checking the pinCode is the first thing I do.
So
> in UserSessionBean (the actual EJB), this is what I was doing:
>
> SessionContext context;
> UserTransaction ut;
> Connection con;
>
> public int checkPinCode ( String pinCode )
> throws RemoteException
> {
> // obtain user transaction interface
> ut = context.getUserTransaction();
> // start a transaction
> try {
> ut.begin();
> } catch ( javax.transaction.NotSupportedException e ) {
> throw new RemoteException ( "transaction not supported" );
> } catch ( javax.transaction.SystemException e ) {
> throw new RemoteException ( "transaction system exception " +
> e );
> }
> try {
> makeConnection();
> } catch (Exception ex) {
> throw new RemoteException("Unable to connect to database. " +
> ex.getMessage());
> }
>
> try {
> // do the actual mess with the database...
> con.close ();
> } catch ( Exception ex ) {
> System.out.println ( "could not check pinCode: " + ex );
> throw new RemoteException ( "checkPinCode: " + ex.getMessage
> () );
> }
> return 0;
> }
>
> Of course, when everything finishes, I'd have to call ut.commit () (in the
> finishRegistration () method) or rollback on time out, etc...
>
> I'd be interested to read any comments on this, as I am at least going to
> try out the darn thing, unless someone tells me to just not.
>
> regards,
>
> candide
>
>
> > You're right, you have a problem.
> >
> > Just off the cuff, here's what I'd think about doing.
> >
> > I assume this is a web app? this makes it hurt worse.
> >
> > This is an awfully long transaction. You really don't want a real
> > transaction open this long. Therefore, I'd use the HTTP Session to store
> > up all the information I need, then make a call to a stateless session
> > bean that does all of it in one transaction. I've made comments below on
> > what I'd do differently.
> >
> >
> > On Sat, 3 Mar 2001, fractals wrote:
> >
> > > Hi,
> > >
> > > This is a very simple question concerning transactions:
> > >
> > > I need to make a user-registration in multiple steps:
> > >
> > > 1. The user enters a pin code that corresponds to a certain amount of
> money
> > > he/she spent to get access to the application
> > > -> application checks the pin code, and marks a corresponding
> pinCode
> > > EJB that the pin code is now used (it cannot be used by another user
at
> the
> > > same time)
> > Mark the pinCode EJB 'reserved' at this point, so that we can tell this
> > 'in process' stuff from actually used pin codes. Save the PIN in the
> > session.
> >
> > >
> > > 2. The user sets his/her pseudo
> > > -> application creates a new User EJB
> > > -> application validates pseudo
> > Just save the pseudo in the HTTP Session. Probably build a bean that
holds
> > pseude, password, and preferences in the session. make that bean
implement
> > the session binding listener stuff, so it knows when it times out.
> >
> > >
> > > 3. The user sets his/her password
> > > -> application validates password
> > > -> application sets the password on the User EJB
> > Put the password in the same bean. Still no access to any User EJB
> >
> > >
> > > 4. The user sets preferences and provides additional info
> > > -> application stores the data on the User EJB
> > Put this in the same bean. No User EJB yet.
> >
> > >
> > > 5. The user terminates and is prompted to log in
> > > -> everything's OK, the transaction can commit
> > Call a session bean, passing it all the stuff we have in the session
that
> > creates the user, sets password and all prefs, etc, then marks the
pinCode
> > EJB 'used'. Tell the bean (the session thingy) that he's done then
remove
> > him from the session.
> >
> > >
> > > At any point, the user can leave is/her chair/terminal so everything
has
> to
> > > be rolled back after a given amount of time. This also means that the
> > > temporary objects (rows), like the User EJB, have to be deleted.
> > Since we haven't created anything, there isn't much to do. Remember that
> > the bean in the session implemented the session binding listener
> > stuff? That means that if he gets unbound before we tell him to complete
> > (because the session timed out), he can clean up, which will consist of
> > setting the pinCode EJB to 'unused' from 'reserved'
> >
> >
> > What all this does is layers the user's logical unit of work over the
top
> > of the low-level transactions. One happy result is that we have a lot
less
> > transaction load hitting the EJB container, which will let it scale
> > better. An unhappy result is that we're making our HTTP sessions bigger,
> > which will effect the JSP/Servlet container's ability to scale. Make
sure
> > anthing you put into the HTTP Session is serializable so it can be
swapped
> > out. Consider saving session state in a temporary database (either
> > directly from the JSP/servlet or via a tempuser EJB) to conserve memory.
> >
> >
> > >
> > > I'm not sure I've well understood the transaction mechanism. In
> particular,
> > > I don't understand when the transaction really begins and ends. As far
> as I
> > > got it, the transaction is a call-level mechanism: if a method is
called
> on
> > > an object and that method calls another method of another object, the
> whole
> > > call chain forms the transaction. What I really need is a client to
make
> a
> > > call to an object's method, then later, when my client makes a call to
> > > another object's method, to be able, if anything goes wrong, to undo
> what
> > > was done before when the first object's method was called. I think the
> > > following settings don't allow for such a thing:
> > >
> > > <ejb-jar>
> > > ...
> > > <assembly-descriptor>
> > > ...
> > > <container-transaction>
> > > <method>
> > > <ejb-name>User</ejb-name>
> > > <method-name>*</method-name>
> > > </method>
> > > <trans-attribute>Required</trans-attribute>
> > > </container-transaction>
> > > <container-transaction>
> > > <method>
> > > <ejb-name>PinCode</ejb-name>
> > > <method-name>markUsed</method-name>
> > > </method>
> > > <trans-attribute>Required</trans-attribute>
> > > </container-transaction>
> > > </assembly-descriptor>
> > > </ejb-jar>
> > >
> > >
> > > _______________________________________________
> > > JBoss-user mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> > >
> >
> > --
> > Dan Christopherson (danch)
> > nVisia Technical Architect (www.nvisia.com)
> >
> > Opinions expressed are mine and do not neccessarily reflect any
> > position or opinion of nVISIA.
> >
>
> --------------------------------------------------------------------------
> -
> > If you're a capitalist and you have the best goods and they're
> > free, you don't have to proselytize, you just have to wait.
> > -Eben Moglen
> >
> >
> > _______________________________________________
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-user
> >
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
