Hi,
I'm not sure why what you are doing doesn't work, but even more I don't
understand why you are trying to manage the transactions yourself. I would
expect the code you show to be in a session bean. From a bean, you can
call setRollbackOnly() on the EJBContext to force the cmt to be rolled back
when the container decides it's over. Is there some reason this won't work
for you? If this is "inside" another transaction you can put the code in a
separate method with RequiresNew transaction attribute.
david jencks
On 2001.05.24 15:30:07 -0400 David Esposito wrote:
> Howdy people ...
>
> I have been building a client application that needs to manipulate
> several
> tables through CMP Entity beans ... I read the post on 4/29 about
> UserTransaction getting added to the JBOSS source. I downloaded
> yesterday's
> snapshot of JBOSS (jboss-cvs.zip (5-23-01)) and took a crack at it ..
>
> I am using:
> Sun JDK 1.3
> PostGreSQL 7.1
> Windows 2000 Server
> my CMP Entity Bean has a "Required" transaction attribute
>
> Here's the summary of my problem: After issuing the commit() on the
> transaction object, my changes are gone forever..
>
> My usage of UserTransaction is simple ... I start a transaction with
> begin()
> ... then i go to the home interface and use a finder to get a bunch of
> objects ... I grab the first object in the enumeration, do some
> hullabaloo
> with it, then do a "setRecord" (it just a shortcut to set all of the
> bean's
> fields) .. then i issue a commit() ... i've trimmed out some stuff to
> make
> the following readable. The name of my bean is "Event" ... (yah, probably
> a
> bad name, but whatever... ;)) ...
>
>
> try{
> initialContext = new InitialContext(env);
> log("Got initial context...");
>
> eventHome =
> (EventHome)getHome(initialContext,"myblah/Event",EventHome.class);
> log("Got EventHome interface...");
>
> trans =
> (UserTransaction)getHome(initialContext,"UserTransaction",UserTransaction.cl
> ass);
> log("Got UserTransaction interface");
> }
> catch(NamingException e){
> log("NamingException during run() method initialization! " + e);
> return;
> }
>
> Event event = null;
> int eventNumber = 0;
>
> while(event != null || eventNumber++ == 0)
> {
> //We need to begin the transaction here ... if we don't, then the
> //call to findByStatus...() is considered part of a different
> transaction
> //and is not encapsulated ...
>
> try{ //Transaction block
>
> trans.begin();
> log("Transaction begun...");
>
> //Let's try to find an event
> try{
> Enumeration eventList =
> eventHome.findByStatusOrderByPriority(EventRecord.STATUS_NEW);
>
> //Reset the event
> event = null;
>
> //Grab the highest priority event out of the
> Enumeration
> if(eventList != null && eventList.hasMoreElements())
> event = (Event)eventList.nextElement();
> }
> catch(FinderException fe){;}
> catch(RemoteException re){
> log("RemoteException while trying to get list of
> pending events! " + re);
> }
>
> //If an event was found, handle it
> if(event != null)
> {
> EventRecord eventRec = event.getRecord();
> log("This event is outstanding:" +
> eventRec.event_id);
> //log(eventRec.toString());
>
> //Biz logic here ....
>
> eventRec.update_date = new
>Timestamp(System.currentTimeMillis());
>
> if(EventRecord.STATUS_COMPLETE.equals(eventRec.status))
> eventRec.completion_date = eventRec.update_date;
>
> log("-----------BEFORE UPDATE---------");
> log(eventRec.toString());
>
> event.setRecord(eventRec);
>
> log("-----------AFTER UPDATE---------");
> log(event.getRecord().toString());
> log("EventRecord has been updated...");
> }
>
> //Unless an exception was thrown, commit it
> trans.commit();
> log("Transaction committed...");
> log("-----------AFTER COMMIT---------");
> log(event.getRecord().toString());
>
>
> }
> catch(Exception e){
> log("Exception caught during event handling block! " +
> e);
> try{
> trans.rollback();
> log("Transaction rollback succeeded...");
> }
> catch(Exception rbe){
> log("Rollback failed!!!");
> }
> }
> }
>
>
> Here's what gets output:
>
> -----------------------------------------------------------------------begin
> Trying to create InitialContext...
> Got initial context...
> lookup name: myblah/Event
> Got EventHome interface...
> lookup name: UserTransaction
> Got UserTransaction interface
> Transaction begun...
> This event is outstanding:5
> -----------BEFORE UPDATE---------
> event_id = 5
> creation_date = 2001-05-23 15:45:59.35
> start_after_date = 2001-05-23 15:45:59.35
> update_date = 2001-05-24 15:19:27.731
> completion_date = null
> event_priority = 50
> event_type = CatalogItemEvent
> status = ERROR
> status_detail =
>
> -----------AFTER UPDATE---------
> event_id = 5
> creation_date = 2001-05-23 15:45:59.35
> start_after_date = 2001-05-23 15:45:59.35
> update_date = 2001-05-24 15:19:27.731
> completion_date = null
> event_priority = 50
> event_type = CatalogItemEvent
> status = ERROR
> status_detail =
>
> EventRecord has been updated...
> Transaction committed...
> -----------AFTER COMMIT---------
> event_id = 5
> creation_date = 2001-05-23 15:45:59.35
> start_after_date = 2001-05-23 15:45:59.35
> update_date = null
> completion_date = null
> event_priority = 50
> event_type = CatalogItemEvent
> status = NEW
> status_detail = null
>
> Transaction begun...
> This event is outstanding:5
> ------------------------------------------------------------------------snip
>
>
> <on and on we go> ... notice how the AFTER COMMIT snapshot of the bean
> has
> rolled back to the previously committed version
>
> There are no exceptions thrown ... everything seems dandy ... but for the
> fact that my changes don't get committed, i'd be quite happy .. ;) ..
>
> What else can I do to debug this problem? My entrance into the world of
> open
> source and J2EE is rather recent so I don't even know where to begin
> looking
> at source code. I've tried a bunch of things ... moving the begin() and
> commit() calls to different sections of the application (just wrapping
> the
> setRecord() call, for instance) .. without using UserTransaction, my
> changes
> get committed just fine (without the possibility of rollback, of course)
> ...
> so my bean seems to be fine ...
>
> Any thoughts?
>
> Thanks in advance.
>
> -Dave
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
