On 2002.09.05 15:51:41 -0400 Bruce Snyder wrote:
> This one time, at band camp, David Jencks said:
>
> DJ>xa has nothing to do with this. If your requirement is for long
> lasting
> DJ>interactive transactions, you need to do (2) or (I should have thought
> of
> DJ>this before) use stateful session beans, which should work with your
> DJ>current method calls.
>
> Actually I was just speaking to a coworker about this. I said that we
> could
> make use of a stateful session bean to hold all changes until a commit
> truly
> needed to be done. The real problem with this is that some changes must
> be
> committed for subsequent operations (within the same tx) can be properly
> performed. This would then disallow rolling back all actions and what
> lead me
> to asking about xa transactions.
Umm do you mean that some changes need to be written to the db so they can
be visible to later db access within the same transaction? If you run a
finder or remove operation all changes within the tx will be written to
disk (first). I'm not sure how you could reread anything affected
otherwise, but if you need to you could probably find a way to call
GlobalTxEntityMap.synchronizeEntitiesWithinTransaction.
Again, xa has nothing to do with this.
david
>
> DJ>> Option 2 is certainly doable, but I really don't like the idea of a
> DJ>> client
> DJ>> performing JNDI lookups. In my mind that seems to violate boundaries
> DJ>> (but, of
> DJ>> course, I could be wrong).
> DJ>
> DJ>Don't you do jndi lookups to find the session home?
>
> Damn you're good, David! I wondered if you'd ask me about that! (That's
> why I like reading your answers.) Yes, but it is compartmentalized into
> a broker object.
>
> DJ>A stateful session bean is probably a better idea since I think you
> could
> DJ>figure out a way to rollback transactions that have remained open too
> long
> DJ>(like maybe the client crashed, user went to lunch, etc). If you can
> DJ>guarantee that the client will really end the tx, I don't see much
> DJ>difference between a client side ut or a stateful session bean that
> does
> DJ>the same operations.
>
> Yes, that's what it's coming down to in my mind - six of one, half dozen
> of
> the other. I need to get further clarification on the requirement that is
> causing me all this strife.
>
> Thanks very much for your feeback, David. Your knowledge and your ability
> to
> continue to remain active on this list is truly a value.
>
> Bruce
> --
> perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone? Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
>
>
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
