One more question, if ObjectWeb's JOTM is using HOWL and it is a Tx
manager, so why Geronimo is uing it's own Tx manager ?
On Tue, Mar 18, 2008 at 11:45 AM, Mohammad Nour El-Din
<[EMAIL PROTECTED]> wrote:
> So interesting, so they developed everything in Java Tx management ???
> sounds strange ha !
>
>
>
> On Mon, Mar 17, 2008 at 8:28 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> > There isn't much active development on it because the project is
> > basically done. The project has a narrowly focused, write a
> > transaction logging system. The project was complete a few years ago
> > and all known bugs have been fixed.
> >
> > So although there is no active development, this code is used in
> > Geronimo TX and some ObjectWeb projects.
> >
> > -dain
> >
> >
> >
> > On Mar 17, 2008, at 1:28 AM, Mohammad Nour El-Din wrote:
> >
> > > I looked at the HOWL project at ObjectWeb and seems that it is an old
> > > project and no further development is made, so why we use it ?
> > >
> > > On Sun, Mar 16, 2008 at 8:07 PM, Dain Sundstrom <[EMAIL PROTECTED]>
> wrote:
> > >> After thinking about this more, I don't think that we should turn on
> > >> recovery at this point in the 3.0 release cycle. I think it is good
> > >> turning it on in trunk (3.1) so we can get lots of testing in before
> > >> releasing it.
> > >>
> > >> One other thing, the tx logs should be in a directory in the data
> > >> directory. I'm not sure if that is happening now but the property
> > >> should be something like data/txlog.
> > >>
> > >> -dain
> > >>
> > >>
> > >>
> > >> On Mar 16, 2008, at 10:03 AM, Dain Sundstrom wrote:
> > >>
> > >>> On Mar 16, 2008, at 9:33 AM, David Jencks wrote:
> > >>>
> > >>>>
> > >>>> On Mar 15, 2008, at 2:37 PM, David Blevins wrote:
> > >>>>
> > >>>>>
> > >>>>> On Mar 15, 2008, at 12:06 AM, David Jencks wrote:
> > >>>>>
> > >>>>>> While not ideal, I think using a working although slower
> > >>>>>> transport is a reasonable compromise to a faster, broken
> > >>>>>> transport until we can get a fixed activemq out.
> > >>>>>
> > >>>>> We definitely need the vm transport for the embedded testing
> > >>>>> scenarios and we don't have tx recovery yet, so this is something
> > >>>>> we probably don't want enable by default. We can wrap the
> > >>>>> wrapping with the "duct tape" flag like so:
> > >>>>>
> > >>>>> if (System.getProperty("duct tape") != null) {
> > >>>>> xaResource = new WrapperNamedXAResource(xaResource,
> > >>>>> container.getContainerID().toString());
> > >>>>> }
> > >>>>> EndpointHandler endpointHandler = new EndpointHandler(container,
> > >>>>> deploymentInfo, instanceFactory, xaResource);
> > >>>>>
> > >>>>> If you have time to make the change and rollback the service-
> > >>>>> jar.xml settings, that'd be great, otherwise I'll get to it before
> > >>>>> we release.
> > >>>>
> > >>>> You should probably check my work :-) but after some work I think
> > >>>> the current status is:
> > >>>>
> > >>>> - recovery works if howl log configured in tm configuration
> > >>>> - there's a flag TxRecovery for MDB container and the DBCP pools
> > >>>> that turns on the NamedXAResource wrapping
> > >>>> - recovery and wrapping is turned on for standalone and tomcat, and
> > >>>> these use the amq tcp transport
> > >>>> - recovery and wrapping is turned off for embedded and it uses vm
> > >>>> transport
> > >>>>
> > >>>> The tests break if you turn on recovery and wrapping in embedded
> > >>>> because the howl log locks its log files and does not unlock them.
> > >>>> Without a "stop" lifecycle call I don't know how the howl log can
> > >>>> determine its time for a clean shutdown.
> > >>>
> > >>> How about a finalizer (assuming we have a point where the log is
> > >>> GCed)? We could subclass the howl log service in OpenEJB and add
> > >>> the finalizer.
> > >>>
> > >>> -dain
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > Thanks
> > > - Mohammad Nour
> >
> >
>
>
>
> --
> Thanks
> - Mohammad Nour
>
--
Thanks
- Mohammad Nour
