Re: container - transaction tag - Weblogic

This is a discussion on Re: container - transaction tag - Weblogic ; Presently all methods of an entity bean run in a transaction. As a result each method locks the entity bean there by making it unusable by any other method. I think to avoid this I would need to change the ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Re: container - transaction tag

  1. Re: container - transaction tag


    Presently all methods of an entity bean run in a transaction. As a result each
    method locks the entity bean there by making it unusable by any other method.
    I think to avoid this I would need to change the tag in ejb-jar.xml
    from "Required" to "Never" for each method. Even after doing that, I get the same
    effect.
    My whole idea is to run each entity bean method outside a transaction context.

    Can anyone please suggest me a way to do that .

    Thanks in advance.

  2. Re: container - transaction tag


    I don't think I believe you, because the "Never" transaction attribute means that
    not only will the container not create a transaction to invoke the method, it
    will actually throw an exception if an attempt is made to invoke the method from
    a thread with an existing transaction context.

    Anyway. the "NotSupported" transaction attribute will cause the container to call
    the method outside of any transaction context. If the calling thread has no existing
    transaction then a new one will not be created, and if the calling thread has
    an existing transaction then that transaction will be suspended while the method
    is called.

    Hope this helps...

    Mark

    "K W" wrote:
    >
    >Presently all methods of an entity bean run in a transaction. As a result
    >each
    >method locks the entity bean there by making it unusable by any other
    >method.
    >I think to avoid this I would need to change the tag
    >in ejb-jar.xml
    >from "Required" to "Never" for each method. Even after doing that, I
    >get the same
    >effect.
    >My whole idea is to run each entity bean method outside a transaction
    >context.
    >
    >Can anyone please suggest me a way to do that .
    >
    >Thanks in advance.



  3. Re: container - transaction tag

    Well,

    For Weblogic you still get a "local" transaction for the duration of the
    EJB call whether you want it or not (if necessary it suspends any
    current transaction before the call and start the "local" one).

    You can play with the TransactionManager or the Weblogic TxHelper class
    to suspend that transaction and then resume it at the end of the call
    but if you are doing CMP then it could lead to data corruption.

    A much cleaner way of doing this is to use a plain DataSource and not a
    TXDataSource that doesn't care about any transaction already in progress
    and the connections that you get from it are not transaction aware.

    HTH,
    Dejan

    Mark Shaffer wrote:

    >I don't think I believe you, because the "Never" transaction attribute means that
    >not only will the container not create a transaction to invoke the method, it
    >will actually throw an exception if an attempt is made to invoke the method from
    >a thread with an existing transaction context.
    >
    >Anyway. the "NotSupported" transaction attribute will cause the container to call
    >the method outside of any transaction context. If the calling thread has no existing
    >transaction then a new one will not be created, and if the calling thread has
    >an existing transaction then that transaction will be suspended while the method
    >is called.
    >
    >Hope this helps...
    >
    >Mark
    >
    >"K W" wrote:
    >
    >
    >>Presently all methods of an entity bean run in a transaction. As a result
    >>each
    >>method locks the entity bean there by making it unusable by any other
    >>method.
    >>I think to avoid this I would need to change the tag
    >>in ejb-jar.xml
    >>
    >>
    >>from "Required" to "Never" for each method. Even after doing that, I

    >
    >
    >>get the same
    >>effect.
    >>My whole idea is to run each entity bean method outside a transaction
    >>context.
    >>
    >>Can anyone please suggest me a way to do that .
    >>
    >>Thanks in advance.
    >>
    >>

    >
    >
    >



  4. Re: container - transaction tag

    Hi Deyan,

    That's all correct. Myself I'm wondering what "usability by any other method"
    means in the original post. Knowing that we should be able to give a right
    answer:

    "As a result each method locks the entity bean there by making it unusable
    by any other method"



    Regards,

    Slava Imeshev

    "Deyan D. Bektchiev" wrote in message news:40072ea9$1@newsgroups.bea.com...
    > Well,
    >
    > For Weblogic you still get a "local" transaction for the duration of the
    > EJB call whether you want it or not (if necessary it suspends any
    > current transaction before the call and start the "local" one).
    >
    > You can play with the TransactionManager or the Weblogic TxHelper class
    > to suspend that transaction and then resume it at the end of the call
    > but if you are doing CMP then it could lead to data corruption.
    >
    > A much cleaner way of doing this is to use a plain DataSource and not a
    > TXDataSource that doesn't care about any transaction already in progress
    > and the connections that you get from it are not transaction aware.
    >
    > HTH,
    > Dejan
    >
    > Mark Shaffer wrote:
    >
    > >I don't think I believe you, because the "Never" transaction attribute means that
    > >not only will the container not create a transaction to invoke the method, it
    > >will actually throw an exception if an attempt is made to invoke the method from
    > >a thread with an existing transaction context.
    > >
    > >Anyway. the "NotSupported" transaction attribute will cause the container to call
    > >the method outside of any transaction context. If the calling thread has no existing
    > >transaction then a new one will not be created, and if the calling thread has
    > >an existing transaction then that transaction will be suspended while the method
    > >is called.
    > >
    > >Hope this helps...
    > >
    > >Mark
    > >
    > >"K W" wrote:
    > >
    > >
    > >>Presently all methods of an entity bean run in a transaction. As a result
    > >>each
    > >>method locks the entity bean there by making it unusable by any other
    > >>method.
    > >>I think to avoid this I would need to change the tag
    > >>in ejb-jar.xml
    > >>
    > >>
    > >>from "Required" to "Never" for each method. Even after doing that, I

    > >
    > >
    > >>get the same
    > >>effect.
    > >>My whole idea is to run each entity bean method outside a transaction
    > >>context.
    > >>
    > >>Can anyone please suggest me a way to do that .
    > >>
    > >>Thanks in advance.
    > >>
    > >>

    > >
    > >
    > >

    >




  5. Re: container - transaction tag

    Hi Slava,

    If the EJB has in "Exclusive" concurrency no one will be able to access
    the instance anyway until the local transaction completes.

    If the original post meant that the data was locked then either
    suspending the local transaction or using a plain DataSource would solve
    the data availability as it will only be locked by the DB until the JDBC
    transaction completes which might be the same duration as the EJB
    transaction (but just coordinated by the calling code) and then it would
    be just coding overhead to get rid of the EJB transaction in the first
    place.

    Personally I prefer making all Entity EJBs "Required" and where I really
    need separate transaction set to "RequiresNew". For Session EJBs it's a
    different story and there "NotSupported" makes sense sometimes (we have
    some session EJBs that can execute for 30 minutes or more and locking
    too many resources for that long really takes the scalability away).

    So the answer to the original issue might be to just set the concurrency
    to "Database" or "Optimistic" and do findByPK from all of the other
    threads that need to do the EJB access.
    Plus the benefit of using "Required" with Weblogic is that should you
    ever reenter (or access multiple times) your EJB you get the same
    instance if you are running inside a transaction and the instance was
    already part of it -- thus reducing stale data access.


    Regards,
    Dejan

    Slava Imeshev wrote:

    >Hi Deyan,
    >
    >That's all correct. Myself I'm wondering what "usability by any other method"
    >means in the original post. Knowing that we should be able to give a right
    >answer:
    >
    >"As a result each method locks the entity bean there by making it unusable
    >by any other method"
    >
    >
    >
    >Regards,
    >
    >Slava Imeshev
    >
    >"Deyan D. Bektchiev" wrote in message news:40072ea9$1@newsgroups.bea.com...
    >
    >
    >>Well,
    >>
    >>For Weblogic you still get a "local" transaction for the duration of the
    >>EJB call whether you want it or not (if necessary it suspends any
    >>current transaction before the call and start the "local" one).
    >>
    >>You can play with the TransactionManager or the Weblogic TxHelper class
    >>to suspend that transaction and then resume it at the end of the call
    >>but if you are doing CMP then it could lead to data corruption.
    >>
    >>A much cleaner way of doing this is to use a plain DataSource and not a
    >>TXDataSource that doesn't care about any transaction already in progress
    >>and the connections that you get from it are not transaction aware.
    >>
    >>HTH,
    >>Dejan
    >>
    >>Mark Shaffer wrote:
    >>
    >>
    >>
    >>>I don't think I believe you, because the "Never" transaction attribute means that
    >>>not only will the container not create a transaction to invoke the method, it
    >>>will actually throw an exception if an attempt is made to invoke the method from
    >>>a thread with an existing transaction context.
    >>>
    >>>Anyway. the "NotSupported" transaction attribute will cause the container to call
    >>>the method outside of any transaction context. If the calling thread has no existing
    >>>transaction then a new one will not be created, and if the calling thread has
    >>>an existing transaction then that transaction will be suspended while the method
    >>>is called.
    >>>
    >>>Hope this helps...
    >>>
    >>>Mark
    >>>
    >>>"K W" wrote:
    >>>
    >>>
    >>>
    >>>
    >>>>Presently all methods of an entity bean run in a transaction. As a result
    >>>>each
    >>>>method locks the entity bean there by making it unusable by any other
    >>>>method.
    >>>>I think to avoid this I would need to change the tag
    >>>>in ejb-jar.xml
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>from "Required" to "Never" for each method. Even after doing that, I
    >>>
    >>>
    >>>
    >>>
    >>>>get the same
    >>>>effect.
    >>>>My whole idea is to run each entity bean method outside a transaction
    >>>>context.
    >>>>
    >>>>Can anyone please suggest me a way to do that .
    >>>>
    >>>>Thanks in advance.
    >>>>
    >>>>
    >>>>
    >>>>
    >>>
    >>>
    >>>

    >
    >
    >
    >



  6. Re: container - transaction tag

    Deyan,

    I used to think that having Required on Entity is mandatory.
    Anyway, it would be interesting to hear the author.

    Regards,

    Slava Imeshev



    "Deyan D. Bektchiev" wrote in message news:400743BC.8040309@appl.net...
    > Hi Slava,
    >
    > If the EJB has in "Exclusive" concurrency no one will be able to access
    > the instance anyway until the local transaction completes.
    >
    > If the original post meant that the data was locked then either
    > suspending the local transaction or using a plain DataSource would solve
    > the data availability as it will only be locked by the DB until the JDBC
    > transaction completes which might be the same duration as the EJB
    > transaction (but just coordinated by the calling code) and then it would
    > be just coding overhead to get rid of the EJB transaction in the first
    > place.
    >
    > Personally I prefer making all Entity EJBs "Required" and where I really
    > need separate transaction set to "RequiresNew". For Session EJBs it's a
    > different story and there "NotSupported" makes sense sometimes (we have
    > some session EJBs that can execute for 30 minutes or more and locking
    > too many resources for that long really takes the scalability away).
    >
    > So the answer to the original issue might be to just set the concurrency
    > to "Database" or "Optimistic" and do findByPK from all of the other
    > threads that need to do the EJB access.
    > Plus the benefit of using "Required" with Weblogic is that should you
    > ever reenter (or access multiple times) your EJB you get the same
    > instance if you are running inside a transaction and the instance was
    > already part of it -- thus reducing stale data access.
    >
    >
    > Regards,
    > Dejan
    >
    > Slava Imeshev wrote:
    >
    > >Hi Deyan,
    > >
    > >That's all correct. Myself I'm wondering what "usability by any other method"
    > >means in the original post. Knowing that we should be able to give a right
    > >answer:
    > >
    > >"As a result each method locks the entity bean there by making it unusable
    > >by any other method"
    > >
    > >
    > >
    > >Regards,
    > >
    > >Slava Imeshev
    > >
    > >"Deyan D. Bektchiev" wrote in message news:40072ea9$1@newsgroups.bea.com...
    > >
    > >
    > >>Well,
    > >>
    > >>For Weblogic you still get a "local" transaction for the duration of the
    > >>EJB call whether you want it or not (if necessary it suspends any
    > >>current transaction before the call and start the "local" one).
    > >>
    > >>You can play with the TransactionManager or the Weblogic TxHelper class
    > >>to suspend that transaction and then resume it at the end of the call
    > >>but if you are doing CMP then it could lead to data corruption.
    > >>
    > >>A much cleaner way of doing this is to use a plain DataSource and not a
    > >>TXDataSource that doesn't care about any transaction already in progress
    > >>and the connections that you get from it are not transaction aware.
    > >>
    > >>HTH,
    > >>Dejan
    > >>
    > >>Mark Shaffer wrote:
    > >>
    > >>
    > >>
    > >>>I don't think I believe you, because the "Never" transaction attribute means that
    > >>>not only will the container not create a transaction to invoke the method, it
    > >>>will actually throw an exception if an attempt is made to invoke the method from
    > >>>a thread with an existing transaction context.
    > >>>
    > >>>Anyway. the "NotSupported" transaction attribute will cause the container to call
    > >>>the method outside of any transaction context. If the calling thread has no existing
    > >>>transaction then a new one will not be created, and if the calling thread has
    > >>>an existing transaction then that transaction will be suspended while the method
    > >>>is called.
    > >>>
    > >>>Hope this helps...
    > >>>
    > >>>Mark
    > >>>
    > >>>"K W" wrote:
    > >>>
    > >>>
    > >>>
    > >>>
    > >>>>Presently all methods of an entity bean run in a transaction. As a result
    > >>>>each
    > >>>>method locks the entity bean there by making it unusable by any other
    > >>>>method.
    > >>>>I think to avoid this I would need to change the tag
    > >>>>in ejb-jar.xml
    > >>>>
    > >>>>
    > >>>>
    > >>>>
    > >>>>from "Required" to "Never" for each method. Even after doing that, I
    > >>>
    > >>>
    > >>>
    > >>>
    > >>>>get the same
    > >>>>effect.
    > >>>>My whole idea is to run each entity bean method outside a transaction
    > >>>>context.
    > >>>>
    > >>>>Can anyone please suggest me a way to do that .
    > >>>>
    > >>>>Thanks in advance.
    > >>>>
    > >>>>
    > >>>>
    > >>>>
    > >>>
    > >>>
    > >>>

    > >
    > >
    > >
    > >

    >




  7. Re: container - transaction tag


    My strategy is a little different. In general, if an EJB method updates the database,
    you can't know a priori whether or not it's necessary to include that update in
    a larger, existing transaction. That would depend on the context in which the
    method is being called, and you can't know that at development time. The only
    safe assumption is that it should be so included, so such methods should have
    the "Requires" or "Supported" transaction attributes. An EJB method that performs
    only read operations on the database I usually give the "Supported" attribute,
    so that if there is an existing transaction then it can just use the same connection,
    and if there is not an existing transaction then there is no need for the container
    to start one. Of course there are exceptions, such as methods that are "RequiresNew"
    because you want their updates to commit immediately, and so on.


    "Deyan D. Bektchiev" wrote:
    >Well,
    >
    >For Weblogic you still get a "local" transaction for the duration of
    >the
    >EJB call whether you want it or not (if necessary it suspends any
    >current transaction before the call and start the "local" one).
    >
    >You can play with the TransactionManager or the Weblogic TxHelper class
    >
    >to suspend that transaction and then resume it at the end of the call
    >
    >but if you are doing CMP then it could lead to data corruption.
    >
    >A much cleaner way of doing this is to use a plain DataSource and not
    >a
    >TXDataSource that doesn't care about any transaction already in progress
    >
    >and the connections that you get from it are not transaction aware.
    >
    >HTH,
    >Dejan
    >
    >Mark Shaffer wrote:
    >
    >>I don't think I believe you, because the "Never" transaction attribute

    >means that
    >>not only will the container not create a transaction to invoke the method,

    >it
    >>will actually throw an exception if an attempt is made to invoke the

    >method from
    >>a thread with an existing transaction context.
    >>
    >>Anyway. the "NotSupported" transaction attribute will cause the container

    >to call
    >>the method outside of any transaction context. If the calling thread

    >has no existing
    >>transaction then a new one will not be created, and if the calling thread

    >has
    >>an existing transaction then that transaction will be suspended while

    >the method
    >>is called.
    >>
    >>Hope this helps...
    >>
    >>Mark
    >>
    >>"K W" wrote:
    >>
    >>
    >>>Presently all methods of an entity bean run in a transaction. As a

    >result
    >>>each
    >>>method locks the entity bean there by making it unusable by any other
    >>>method.
    >>>I think to avoid this I would need to change the

    >tag
    >>>in ejb-jar.xml
    >>>
    >>>
    >>>from "Required" to "Never" for each method. Even after doing that,

    >I
    >>
    >>
    >>>get the same
    >>>effect.
    >>>My whole idea is to run each entity bean method outside a transaction
    >>>context.
    >>>
    >>>Can anyone please suggest me a way to do that .
    >>>
    >>>Thanks in advance.
    >>>
    >>>

    >>
    >>
    >>

    >



+ Reply to Thread