On Fri, 27 Oct 2000, marc fleury wrote:
> |>In other words... if you have information displayed on the page and you
> |>update some OTHER bean based on that information then it doesn't work
> |>anyhow... I don't know.... is it that useful? A long transaction
> |takes care
> |>of that for everybody and everycase (just let the transaction encompass
> |>several beans by propagation)... it happens that web transactions are not
> |>"millisecond things", tough tities ...
> |
> |I only glanced at the article.. but I got the impression that the same
> |versioning info would go to the db table... so wouldn't updates from other
> |beans get sync'd via ejbLoad() ?
>
> what I am saying is
>
> statefulA display entityB and updates entity C
>
> (buy car session is sA, bankAccount is eB, and orderSlip is eC)
>
> if sA displays bank account availability from eB to take a decision to buy
> and issue an eC, then you can't make sure, with the strategy outlined in the
> paper that information based on eB is still valid when you do so, unless you
> actually call eB again. (I wasn't talking about 2 beans representing the
> same entity).
I really think that at this point you're getting into scenarios that are
better handled within the application. In fact, assuming a 'normal'
implementation, this would be OK because eC would be a create, right?
>
> The strategy only works for
>
> sA reads and updates eB only.
>
> The strategy needs to be extended to "check eB again before commiting to
> eC", which is the right way to do it imho.
> I guess n calls to the n-entities involved is better than one transaction...
> I don't know...
>
> marc
> |
> |Anyhow, as for it's usefulness... I have no clue.
> |
> |-- Juha
> |
> |
> |>
> |>marc
> |>
> |>|
> |>|I mean we need to keep the "id" version associated with the
> |client somehow,
> |>|and that can only be with the proxy...
> |>|
> |>|now we need to send and return the version numbers with every
> |>|call... fine a
> |>|little overhead but I guess we can live with it.
> |>|
> |>|then we need to trap that in the client and fire an exception if
> |there is a
> |>|version missmatch exception? as what?
> |>|
> |>|interesting... what do you folks think of that feature? is it
> |really kosher
> |>|with EJB (exception and all)
> |>|
> |>|
> |>|marc
> |>|
> |>||-----Original Message-----
> |>||From: [EMAIL PROTECTED]
> |>||[mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> |>||Sent: Friday, October 27, 2000 4:42 AM
> |>||To: jBoss User
> |>||Subject: [jBoss-User] Long-running pseudo transactions HOWTO
> |>||
> |>||
> |>||Hey
> |>||
> |>||In the latest newsletter from TheServerSide.com there is a great tip on
> |>||how to solve long running transactions (i.e. how to resolve conflicts
> |>||between two users simultaneously viewing and editing EntityBean data).
> |>||
> |>||Read it here:
> |>||http://www.TheServerSide.com/resources/news3.html
> |>||
> |>||regards,
> |>|| Rickard
> |>||
> |>||ps. Ingo, this answers your comp.lang.java.beans question re: concurrent
> |>||control to EntityBeans!
> |>||
> |>||--
> |>||Rickard �berg
> |>||
> |>||Email: [EMAIL PROTECTED]
> |>||http://www.telkel.com
> |>||http://www.jboss.org
> |>||http://www.dreambean.com
> |>||
> |>||
> |>||
> |>||--
> |>||--------------------------------------------------------------
> |>||To subscribe: [EMAIL PROTECTED]
> |>||To unsubscribe: [EMAIL PROTECTED]
> |>||Problems?: [EMAIL PROTECTED]
> |>||
> |>||
> |>|
> |>|
> |>|
> |>|--
> |>|--------------------------------------------------------------
> |>|To subscribe: [EMAIL PROTECTED]
> |>|To unsubscribe: [EMAIL PROTECTED]
> |>|Problems?: [EMAIL PROTECTED]
> |>|
> |>|
> |>
> |>
> |>
> |>--
> |>--------------------------------------------------------------
> |>To subscribe: [EMAIL PROTECTED]
> |>To unsubscribe: [EMAIL PROTECTED]
> |>Problems?: [EMAIL PROTECTED]
> |>
> |>
> |
> |
> |
> |--
> |--------------------------------------------------------------
> |To subscribe: [EMAIL PROTECTED]
> |To unsubscribe: [EMAIL PROTECTED]
> |Problems?: [EMAIL PROTECTED]
> |
> |
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
Dan Christopherson (danch)
nVisia Technical Architect (www.nvisia.com)
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
