Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Inter-component transactions

9 posts in General Discussion (old) Last posting was on 2000-02-22 01:53:49.0Z
Sheila McCall Posted on 2000-02-17 18:02:32.0Z
Newsgroups: sybase.public.easerver
Date: Thu, 17 Feb 2000 18:02:32 +0000
From: Sheila McCall <sheila.mccall@omgroup.com>
Organization: OM Technology
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Inter-component transactions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 33
NNTP-Posting-Host: 194.200.143.49
Message-ID: <347_38AC37B8.5FE400B3@omgroup.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28480
Article PK: 160636

Hi,

I am currently in the process if designing a new module for our client
server application. We are trying to develop the new module in a more OO
fashion with the intent of converting it to 3-tier eventually. We are
currently planning to use stateful objects and are concerned as to how
to implement inter-object transactions when we move to three tier.

For example, User A creates an instance of class A which in turn creates
instances of classes B and C. Any update to A must also update B and C.
Even though objects A, B and C have been created as a result of user A's
actions, each object has it's own transaction object rather than a
transaction object for the client session. Is this correct?

As I understand it, from my very limited knowledge of the subject,
Jaguar's transaction management cannot be used to handle stateful
components. Also, global variables (SQLCA in particular) are not session
based and cannot be used across objects, and transaction objects cannot
be passed as parameters to remote objects.

It is extremely important that we manage to implement a two-tier
solution that will be easily applied to three tier. Any suggestions as
to how to do this would be greatly appreciated as I am getting more
confused by the minute!

Sheila McCall


Mark Maslow Posted on 2000-02-17 19:38:09.0Z
Newsgroups: sybase.public.easerver
From: "Mark Maslow" <mark.maslow@sierraclub.org>
Subject: Re: Inter-component transactions
Date: Thu, 17 Feb 2000 11:38:09 -0800
Lines: 42
Organization: Sierra Club
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
NNTP-Posting-Host: machine001.sierraclub.org 207.90.163.1
Message-ID: <347_rpbJU9Xe$GA.149@forums.sybase.com>
References: <347_38AC37B8.5FE400B3@omgroup.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28464
Article PK: 160622

If components A, B and C support transactions, and A creates instances of B
and C, then when components B and C issue completeWork(), they have voted to
commit the transaction. But it's only when A issues completeWork() that the
entire transaction is actually committed to the database.

This is all very well documented in Chapter 3 of the Jaguar CTS Programmer's
Guide "Jaguar's Transaction Processing Model", which should clear up your
confusion.

Mark Maslow

Sheila McCall <sheila.mccall@omgroup.com> wrote in message
news:38AC37B8.5FE400B3@omgroup.com...
> Hi,
>
> I am currently in the process if designing a new module for our client
> server application. We are trying to develop the new module in a more OO
> fashion with the intent of converting it to 3-tier eventually. We are
> currently planning to use stateful objects and are concerned as to how
> to implement inter-object transactions when we move to three tier.
>
> For example, User A creates an instance of class A which in turn creates
> instances of classes B and C. Any update to A must also update B and C.
> Even though objects A, B and C have been created as a result of user A's
> actions, each object has it's own transaction object rather than a
> transaction object for the client session. Is this correct?
>
> As I understand it, from my very limited knowledge of the subject,
> Jaguar's transaction management cannot be used to handle stateful
> components. Also, global variables (SQLCA in particular) are not session
> based and cannot be used across objects, and transaction objects cannot
> be passed as parameters to remote objects.
>
> It is extremely important that we manage to implement a two-tier
> solution that will be easily applied to three tier. Any suggestions as
> to how to do this would be greatly appreciated as I am getting more
> confused by the minute!
>
> Sheila McCall
>


Sheila McCall Posted on 2000-02-18 08:47:42.0Z
Newsgroups: sybase.public.easerver
Date: Fri, 18 Feb 2000 08:47:42 +0000
From: Sheila McCall <sheila.mccall@omgroup.com>
Organization: OM Technology
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: Inter-component transactions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 61
NNTP-Posting-Host: 194.200.143.49
Message-ID: <347_38AD072E.8224554@omgroup.com>
References: <347_38AC37B8.5FE400B3@omgroup.com> <347_rpbJU9Xe$GA.149@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28411
Article PK: 160432

Thanks for the reply.

Isn't it the case though that stateful objects cannot participate in Jaguar
transactions - ie they have to be set to transactions not supported? If this is
true, how can we manually maintain out own transactions across objects A, B and
C while using stateful objects? If Jaguar now supports stateful object
transaction then I agree there should not be a problem.

Sheila

Mark Maslow wrote:

> If components A, B and C support transactions, and A creates instances of B
> and C, then when components B and C issue completeWork(), they have voted to
> commit the transaction. But it's only when A issues completeWork() that the
> entire transaction is actually committed to the database.
>
> This is all very well documented in Chapter 3 of the Jaguar CTS Programmer's
> Guide "Jaguar's Transaction Processing Model", which should clear up your
> confusion.
>
> Mark Maslow
>
> Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> news:38AC37B8.5FE400B3@omgroup.com...
> > Hi,
> >
> > I am currently in the process if designing a new module for our client
> > server application. We are trying to develop the new module in a more OO
> > fashion with the intent of converting it to 3-tier eventually. We are
> > currently planning to use stateful objects and are concerned as to how
> > to implement inter-object transactions when we move to three tier.
> >
> > For example, User A creates an instance of class A which in turn creates
> > instances of classes B and C. Any update to A must also update B and C.
> > Even though objects A, B and C have been created as a result of user A's
> > actions, each object has it's own transaction object rather than a
> > transaction object for the client session. Is this correct?
> >
> > As I understand it, from my very limited knowledge of the subject,
> > Jaguar's transaction management cannot be used to handle stateful
> > components. Also, global variables (SQLCA in particular) are not session
> > based and cannot be used across objects, and transaction objects cannot
> > be passed as parameters to remote objects.
> >
> > It is extremely important that we manage to implement a two-tier
> > solution that will be easily applied to three tier. Any suggestions as
> > to how to do this would be greatly appreciated as I am getting more
> > confused by the minute!
> >
> > Sheila McCall
> >


Dave Wolf [Sybase] Posted on 2000-02-18 13:21:52.0Z
Newsgroups: sybase.public.easerver
From: "Dave Wolf [Sybase]" <dwolf@sybase.com>
Subject: Re: Inter-component transactions
Date: Fri, 18 Feb 2000 08:21:52 -0500
Lines: 78
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
NNTP-Posting-Host: 158.159.8.28
Message-ID: <347_HHcffOhe$GA.324@forums.sybase.com>
References: <347_38AC37B8.5FE400B3@omgroup.com> <347_rpbJU9Xe$GA.149@forums.sybase.com> <347_38AD072E.8224554@omgroup.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28405
Article PK: 160427

Not at all. Stateful components can participate in Tx's. Its just in
pre-3.5 the Tx wouldnt be commited/rolledback until the stateful object
deactivated.

Dave Wolf
Internet Applications Division

Sheila McCall <sheila.mccall@omgroup.com> wrote in message
news:38AD072E.8224554@omgroup.com...
> Thanks for the reply.
>
> Isn't it the case though that stateful objects cannot participate in
Jaguar
> transactions - ie they have to be set to transactions not supported? If
this is
> true, how can we manually maintain out own transactions across objects A,
B and
> C while using stateful objects? If Jaguar now supports stateful object
> transaction then I agree there should not be a problem.
>
> Sheila
>
> Mark Maslow wrote:
>
> > If components A, B and C support transactions, and A creates instances
of B
> > and C, then when components B and C issue completeWork(), they have
voted to
> > commit the transaction. But it's only when A issues completeWork() that
the
> > entire transaction is actually committed to the database.
> >
> > This is all very well documented in Chapter 3 of the Jaguar CTS
Programmer's
> > Guide "Jaguar's Transaction Processing Model", which should clear up
your
> > confusion.
> >
> > Mark Maslow
> >
> > Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> > news:38AC37B8.5FE400B3@omgroup.com...
> > > Hi,
> > >
> > > I am currently in the process if designing a new module for our client
> > > server application. We are trying to develop the new module in a more
OO
> > > fashion with the intent of converting it to 3-tier eventually. We are
> > > currently planning to use stateful objects and are concerned as to how
> > > to implement inter-object transactions when we move to three tier.
> > >
> > > For example, User A creates an instance of class A which in turn
creates
> > > instances of classes B and C. Any update to A must also update B and
C.
> > > Even though objects A, B and C have been created as a result of user
A's
> > > actions, each object has it's own transaction object rather than a
> > > transaction object for the client session. Is this correct?
> > >
> > > As I understand it, from my very limited knowledge of the subject,
> > > Jaguar's transaction management cannot be used to handle stateful
> > > components. Also, global variables (SQLCA in particular) are not
session
> > > based and cannot be used across objects, and transaction objects
cannot
> > > be passed as parameters to remote objects.
> > >
> > > It is extremely important that we manage to implement a two-tier
> > > solution that will be easily applied to three tier. Any suggestions as
> > > to how to do this would be greatly appreciated as I am getting more
> > > confused by the minute!
> > >
> > > Sheila McCall
> > >
>


Andrew Hircock Posted on 2000-02-18 14:22:29.0Z
Newsgroups: sybase.public.easerver
Date: Fri, 18 Feb 2000 09:22:29 -0500
From: Andrew Hircock <ahircock@mxi.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: Inter-component transactions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 83
NNTP-Posting-Host: jupiter.mxi.com 209.87.228.68
Message-ID: <347_38AD55A5.109F36C1@mxi.com>
References: <347_38AC37B8.5FE400B3@omgroup.com> <347_rpbJU9Xe$GA.149@forums.sybase.com> <347_38AD072E.8224554@omgroup.com> <347_HHcffOhe$GA.324@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28398
Article PK: 154664

That's great! However, is it still the case that when you run SetComplete() or
SetAbort() the component is deactivated/destroyed? Basically, I'm trying to find
out if it is possible to rollback your transactions, and yet keep the stateful
component alive?

"Dave Wolf [Sybase]" wrote:

> Not at all. Stateful components can participate in Tx's. Its just in
> pre-3.5 the Tx wouldnt be commited/rolledback until the stateful object
> deactivated.
>
> Dave Wolf
> Internet Applications Division
>
> Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> news:38AD072E.8224554@omgroup.com...
> > Thanks for the reply.
> >
> > Isn't it the case though that stateful objects cannot participate in
> Jaguar
> > transactions - ie they have to be set to transactions not supported? If
> this is
> > true, how can we manually maintain out own transactions across objects A,
> B and
> > C while using stateful objects? If Jaguar now supports stateful object
> > transaction then I agree there should not be a problem.
> >
> > Sheila
> >
> > Mark Maslow wrote:
> >
> > > If components A, B and C support transactions, and A creates instances
> of B
> > > and C, then when components B and C issue completeWork(), they have
> voted to
> > > commit the transaction. But it's only when A issues completeWork() that
> the
> > > entire transaction is actually committed to the database.
> > >
> > > This is all very well documented in Chapter 3 of the Jaguar CTS
> Programmer's
> > > Guide "Jaguar's Transaction Processing Model", which should clear up
> your
> > > confusion.
> > >
> > > Mark Maslow
> > >
> > > Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> > > news:38AC37B8.5FE400B3@omgroup.com...
> > > > Hi,
> > > >
> > > > I am currently in the process if designing a new module for our client
> > > > server application. We are trying to develop the new module in a more
> OO
> > > > fashion with the intent of converting it to 3-tier eventually. We are
> > > > currently planning to use stateful objects and are concerned as to how
> > > > to implement inter-object transactions when we move to three tier.
> > > >
> > > > For example, User A creates an instance of class A which in turn
> creates
> > > > instances of classes B and C. Any update to A must also update B and
> C.
> > > > Even though objects A, B and C have been created as a result of user
> A's
> > > > actions, each object has it's own transaction object rather than a
> > > > transaction object for the client session. Is this correct?
> > > >
> > > > As I understand it, from my very limited knowledge of the subject,
> > > > Jaguar's transaction management cannot be used to handle stateful
> > > > components. Also, global variables (SQLCA in particular) are not
> session
> > > > based and cannot be used across objects, and transaction objects
> cannot
> > > > be passed as parameters to remote objects.
> > > >
> > > > It is extremely important that we manage to implement a two-tier
> > > > solution that will be easily applied to three tier. Any suggestions as
> > > > to how to do this would be greatly appreciated as I am getting more
> > > > confused by the minute!
> > > >
> > > > Sheila McCall
> > > >
> >


Dave Wolf [Sybase] Posted on 2000-02-18 14:41:30.0Z
Newsgroups: sybase.public.easerver
From: "Dave Wolf [Sybase]" <dwolf@sybase.com>
Subject: Re: Inter-component transactions
Date: Fri, 18 Feb 2000 09:41:30 -0500
Lines: 108
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
NNTP-Posting-Host: 158.159.8.28
Message-ID: <347_y$9JA7he$GA.149@forums.sybase.com>
References: <347_38AC37B8.5FE400B3@omgroup.com> <347_rpbJU9Xe$GA.149@forums.sybase.com> <347_38AD072E.8224554@omgroup.com> <347_HHcffOhe$GA.324@forums.sybase.com> <347_38AD55A5.109F36C1@mxi.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28394
Article PK: 160418

Not in 3.0 but it is possible in 3.5.

Dave Wolf
Internet Applications Division

Andrew Hircock <ahircock@mxi.com> wrote in message
news:38AD55A5.109F36C1@mxi.com...
> That's great! However, is it still the case that when you run
SetComplete() or
> SetAbort() the component is deactivated/destroyed? Basically, I'm trying
to find
> out if it is possible to rollback your transactions, and yet keep the
stateful
> component alive?
>
> "Dave Wolf [Sybase]" wrote:
>
> > Not at all. Stateful components can participate in Tx's. Its just in
> > pre-3.5 the Tx wouldnt be commited/rolledback until the stateful object
> > deactivated.
> >
> > Dave Wolf
> > Internet Applications Division
> >
> > Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> > news:38AD072E.8224554@omgroup.com...
> > > Thanks for the reply.
> > >
> > > Isn't it the case though that stateful objects cannot participate in
> > Jaguar
> > > transactions - ie they have to be set to transactions not supported?
If
> > this is
> > > true, how can we manually maintain out own transactions across objects
A,
> > B and
> > > C while using stateful objects? If Jaguar now supports stateful object
> > > transaction then I agree there should not be a problem.
> > >
> > > Sheila
> > >
> > > Mark Maslow wrote:
> > >
> > > > If components A, B and C support transactions, and A creates
instances
> > of B
> > > > and C, then when components B and C issue completeWork(), they have
> > voted to
> > > > commit the transaction. But it's only when A issues completeWork()
that
> > the
> > > > entire transaction is actually committed to the database.
> > > >
> > > > This is all very well documented in Chapter 3 of the Jaguar CTS
> > Programmer's
> > > > Guide "Jaguar's Transaction Processing Model", which should clear up
> > your
> > > > confusion.
> > > >
> > > > Mark Maslow
> > > >
> > > > Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> > > > news:38AC37B8.5FE400B3@omgroup.com...
> > > > > Hi,
> > > > >
> > > > > I am currently in the process if designing a new module for our
client
> > > > > server application. We are trying to develop the new module in a
more
> > OO
> > > > > fashion with the intent of converting it to 3-tier eventually. We
are
> > > > > currently planning to use stateful objects and are concerned as to
how
> > > > > to implement inter-object transactions when we move to three tier.
> > > > >
> > > > > For example, User A creates an instance of class A which in turn
> > creates
> > > > > instances of classes B and C. Any update to A must also update B
and
> > C.
> > > > > Even though objects A, B and C have been created as a result of
user
> > A's
> > > > > actions, each object has it's own transaction object rather than a
> > > > > transaction object for the client session. Is this correct?
> > > > >
> > > > > As I understand it, from my very limited knowledge of the subject,
> > > > > Jaguar's transaction management cannot be used to handle stateful
> > > > > components. Also, global variables (SQLCA in particular) are not
> > session
> > > > > based and cannot be used across objects, and transaction objects
> > cannot
> > > > > be passed as parameters to remote objects.
> > > > >
> > > > > It is extremely important that we manage to implement a two-tier
> > > > > solution that will be easily applied to three tier. Any
suggestions as
> > > > > to how to do this would be greatly appreciated as I am getting
more
> > > > > confused by the minute!
> > > > >
> > > > > Sheila McCall
> > > > >
> > >
>


Andrew Hircock Posted on 2000-02-21 18:29:06.0Z
Newsgroups: sybase.public.easerver
Date: Mon, 21 Feb 2000 13:29:06 -0500
From: Andrew Hircock <ahircock@mxi.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: Inter-component transactions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 110
NNTP-Posting-Host: jupiter.mxi.com 209.87.228.68
Message-ID: <347_38B183F1.74297D05@mxi.com>
References: <347_38AC37B8.5FE400B3@omgroup.com> <347_rpbJU9Xe$GA.149@forums.sybase.com> <347_38AD072E.8224554@omgroup.com> <347_HHcffOhe$GA.324@forums.sybase.com> <347_38AD55A5.109F36C1@mxi.com> <347_y$9JA7he$GA.149@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28275
Article PK: 160319

Hi Dave,

How do I rollback the transaction, and yet keep the stateful component
alive/active? You said that it was only in pre-3.5 that Tx's wouldn't be rolled
back until you deactivated the component.

If I run SetAbort(), then the stateful component will be deactivated
immediately...
If I run DisableCommit() the transaction won't be rolled back until I deactivate
the component (which could be a long time away)...

Have DisableCommit() and/or SetAbort() changed?

Thanks

"Dave Wolf [Sybase]" wrote:

> Not in 3.0 but it is possible in 3.5.
>
> Dave Wolf
> Internet Applications Division
>
> Andrew Hircock <ahircock@mxi.com> wrote in message
> news:38AD55A5.109F36C1@mxi.com...
> > That's great! However, is it still the case that when you run
> SetComplete() or
> > SetAbort() the component is deactivated/destroyed? Basically, I'm trying
> to find
> > out if it is possible to rollback your transactions, and yet keep the
> stateful
> > component alive?
> >
> > "Dave Wolf [Sybase]" wrote:
> >
> > > Not at all. Stateful components can participate in Tx's. Its just in
> > > pre-3.5 the Tx wouldnt be commited/rolledback until the stateful object
> > > deactivated.
> > >
> > > Dave Wolf
> > > Internet Applications Division
> > >
> > > Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> > > news:38AD072E.8224554@omgroup.com...
> > > > Thanks for the reply.
> > > >
> > > > Isn't it the case though that stateful objects cannot participate in
> > > Jaguar
> > > > transactions - ie they have to be set to transactions not supported?
> If
> > > this is
> > > > true, how can we manually maintain out own transactions across objects
> A,
> > > B and
> > > > C while using stateful objects? If Jaguar now supports stateful object
> > > > transaction then I agree there should not be a problem.
> > > >
> > > > Sheila
> > > >
> > > > Mark Maslow wrote:
> > > >
> > > > > If components A, B and C support transactions, and A creates
> instances
> > > of B
> > > > > and C, then when components B and C issue completeWork(), they have
> > > voted to
> > > > > commit the transaction. But it's only when A issues completeWork()
> that
> > > the
> > > > > entire transaction is actually committed to the database.
> > > > >
> > > > > This is all very well documented in Chapter 3 of the Jaguar CTS
> > > Programmer's
> > > > > Guide "Jaguar's Transaction Processing Model", which should clear up
> > > your
> > > > > confusion.
> > > > >
> > > > > Mark Maslow
> > > > >
> > > > > Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> > > > > news:38AC37B8.5FE400B3@omgroup.com...
> > > > > > Hi,
> > > > > >
> > > > > > I am currently in the process if designing a new module for our
> client
> > > > > > server application. We are trying to develop the new module in a
> more
> > > OO
> > > > > > fashion with the intent of converting it to 3-tier eventually. We
> are
> > > > > > currently planning to use stateful objects and are concerned as to
> how
> > > > > > to implement inter-object transactions when we move to three tier.
> > > > > >
> > > > > > For example, User A creates an instance of class A which in turn
> > > creates
> > > > > > instances of classes B and C. Any update to A must also update B
> and
> > > C.
> > > > > > Even though objects A, B and C have been created as a result of
> user
> > > A's
> > > > > > actions, each object has it's own transaction object rather than a
> > > > > > transaction object for the client session. Is this correct?
> > > > > >
> > > > > > As I understand it, from my very limited knowledge of the subject,
> > > > > > Jaguar's transaction management cannot be used to handle stateful
> > > > > > components. Also, global variables (SQLCA in particular) are not
> > > session
> > > > > > based and cannot be used across objects, and transaction objects
> > > cannot
> > > > > > be passed as parameters to remote objects.
> > > > > >
> > > > > > It is extremely important that we manage to implement a two-tier
> > > > > > solution that will be easily applied to three tier. Any
> suggestions as
> > > > > > to how to do this would be greatly appreciated as I am getting
> more
> > > > > > confused by the minute!
> > > > > >
> > > > > > Sheila McCall
> > > > > >
> > > >
> >


Dave Wolf [Sybase] Posted on 2000-02-22 01:53:49.0Z
Newsgroups: sybase.public.easerver
From: "Dave Wolf [Sybase]" <dwolf@sybase.com>
Subject: Re: Inter-component transactions
Date: Mon, 21 Feb 2000 20:53:49 -0500
Lines: 161
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
NNTP-Posting-Host: 158.159.8.19
Message-ID: <347_rKAnugNf$GA.333@forums.sybase.com>
References: <347_38AC37B8.5FE400B3@omgroup.com> <347_rpbJU9Xe$GA.149@forums.sybase.com> <347_38AD072E.8224554@omgroup.com> <347_HHcffOhe$GA.324@forums.sybase.com> <347_38AD55A5.109F36C1@mxi.com> <347_y$9JA7he$GA.149@forums.sybase.com> <347_38B183F1.74297D05@mxi.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28258
Article PK: 160300

3.5 has a new threading option called "Bind Object" which if set will let
you call SetComplete() without decoupling the component from the client.
The only way to then destroy the instance is with a timeout.

Dave Wolf
Internet Applications Division

Andrew Hircock <ahircock@mxi.com> wrote in message
news:38B183F1.74297D05@mxi.com...
> Hi Dave,
>
> How do I rollback the transaction, and yet keep the stateful component
> alive/active? You said that it was only in pre-3.5 that Tx's wouldn't be
rolled
> back until you deactivated the component.
>
> If I run SetAbort(), then the stateful component will be deactivated
> immediately...
> If I run DisableCommit() the transaction won't be rolled back until I
deactivate
> the component (which could be a long time away)...
>
> Have DisableCommit() and/or SetAbort() changed?
>
> Thanks
>
> "Dave Wolf [Sybase]" wrote:
>
> > Not in 3.0 but it is possible in 3.5.
> >
> > Dave Wolf
> > Internet Applications Division
> >
> > Andrew Hircock <ahircock@mxi.com> wrote in message
> > news:38AD55A5.109F36C1@mxi.com...
> > > That's great! However, is it still the case that when you run
> > SetComplete() or
> > > SetAbort() the component is deactivated/destroyed? Basically, I'm
trying
> > to find
> > > out if it is possible to rollback your transactions, and yet keep the
> > stateful
> > > component alive?
> > >
> > > "Dave Wolf [Sybase]" wrote:
> > >
> > > > Not at all. Stateful components can participate in Tx's. Its just
in
> > > > pre-3.5 the Tx wouldnt be commited/rolledback until the stateful
object
> > > > deactivated.
> > > >
> > > > Dave Wolf
> > > > Internet Applications Division
> > > >
> > > > Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> > > > news:38AD072E.8224554@omgroup.com...
> > > > > Thanks for the reply.
> > > > >
> > > > > Isn't it the case though that stateful objects cannot participate
in
> > > > Jaguar
> > > > > transactions - ie they have to be set to transactions not
supported?
> > If
> > > > this is
> > > > > true, how can we manually maintain out own transactions across
objects
> > A,
> > > > B and
> > > > > C while using stateful objects? If Jaguar now supports stateful
object
> > > > > transaction then I agree there should not be a problem.
> > > > >
> > > > > Sheila
> > > > >
> > > > > Mark Maslow wrote:
> > > > >
> > > > > > If components A, B and C support transactions, and A creates
> > instances
> > > > of B
> > > > > > and C, then when components B and C issue completeWork(), they
have
> > > > voted to
> > > > > > commit the transaction. But it's only when A issues
completeWork()
> > that
> > > > the
> > > > > > entire transaction is actually committed to the database.
> > > > > >
> > > > > > This is all very well documented in Chapter 3 of the Jaguar CTS
> > > > Programmer's
> > > > > > Guide "Jaguar's Transaction Processing Model", which should
clear up
> > > > your
> > > > > > confusion.
> > > > > >
> > > > > > Mark Maslow
> > > > > >
> > > > > > Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> > > > > > news:38AC37B8.5FE400B3@omgroup.com...
> > > > > > > Hi,
> > > > > > >
> > > > > > > I am currently in the process if designing a new module for
our
> > client
> > > > > > > server application. We are trying to develop the new module in
a
> > more
> > > > OO
> > > > > > > fashion with the intent of converting it to 3-tier eventually.
We
> > are
> > > > > > > currently planning to use stateful objects and are concerned
as to
> > how
> > > > > > > to implement inter-object transactions when we move to three
tier.
> > > > > > >
> > > > > > > For example, User A creates an instance of class A which in
turn
> > > > creates
> > > > > > > instances of classes B and C. Any update to A must also update
B
> > and
> > > > C.
> > > > > > > Even though objects A, B and C have been created as a result
of
> > user
> > > > A's
> > > > > > > actions, each object has it's own transaction object rather
than a
> > > > > > > transaction object for the client session. Is this correct?
> > > > > > >
> > > > > > > As I understand it, from my very limited knowledge of the
subject,
> > > > > > > Jaguar's transaction management cannot be used to handle
stateful
> > > > > > > components. Also, global variables (SQLCA in particular) are
not
> > > > session
> > > > > > > based and cannot be used across objects, and transaction
objects
> > > > cannot
> > > > > > > be passed as parameters to remote objects.
> > > > > > >
> > > > > > > It is extremely important that we manage to implement a
two-tier
> > > > > > > solution that will be easily applied to three tier. Any
> > suggestions as
> > > > > > > to how to do this would be greatly appreciated as I am getting
> > more
> > > > > > > confused by the minute!
> > > > > > >
> > > > > > > Sheila McCall
> > > > > > >
> > > > >
> > >
>


Sheila McCall Posted on 2000-02-18 14:40:30.0Z
Newsgroups: sybase.public.easerver
Date: Fri, 18 Feb 2000 14:40:30 +0000
From: Sheila McCall <sheila.mccall@omgroup.com>
Organization: OM Technology
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: Inter-component transactions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 87
NNTP-Posting-Host: 194.200.143.49
Message-ID: <347_38AD59DE.E3BEEBC@omgroup.com>
References: <347_38AC37B8.5FE400B3@omgroup.com> <347_rpbJU9Xe$GA.149@forums.sybase.com> <347_38AD072E.8224554@omgroup.com> <347_HHcffOhe$GA.324@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28396
Article PK: 160422

Does this mean that I can use stateful components in exactly the same manner as
stateless components as regards Jaguar transactions? I realise that stateful
companents are not as scalable but I think they can be implemented in our
current development much more easlily.

Can you recommend any reading material on this subject as I seem to have been
refering to some material which may be slightly out of date?

Thanks,

Sheila

"Dave Wolf [Sybase]" wrote:

> Not at all. Stateful components can participate in Tx's. Its just in
> pre-3.5 the Tx wouldnt be commited/rolledback until the stateful object
> deactivated.
>
> Dave Wolf
> Internet Applications Division
>
> Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> news:38AD072E.8224554@omgroup.com...
> > Thanks for the reply.
> >
> > Isn't it the case though that stateful objects cannot participate in
> Jaguar
> > transactions - ie they have to be set to transactions not supported? If
> this is
> > true, how can we manually maintain out own transactions across objects A,
> B and
> > C while using stateful objects? If Jaguar now supports stateful object
> > transaction then I agree there should not be a problem.
> >
> > Sheila
> >
> > Mark Maslow wrote:
> >
> > > If components A, B and C support transactions, and A creates instances
> of B
> > > and C, then when components B and C issue completeWork(), they have
> voted to
> > > commit the transaction. But it's only when A issues completeWork() that
> the
> > > entire transaction is actually committed to the database.
> > >
> > > This is all very well documented in Chapter 3 of the Jaguar CTS
> Programmer's
> > > Guide "Jaguar's Transaction Processing Model", which should clear up
> your
> > > confusion.
> > >
> > > Mark Maslow
> > >
> > > Sheila McCall <sheila.mccall@omgroup.com> wrote in message
> > > news:38AC37B8.5FE400B3@omgroup.com...
> > > > Hi,
> > > >
> > > > I am currently in the process if designing a new module for our client
> > > > server application. We are trying to develop the new module in a more
> OO
> > > > fashion with the intent of converting it to 3-tier eventually. We are
> > > > currently planning to use stateful objects and are concerned as to how
> > > > to implement inter-object transactions when we move to three tier.
> > > >
> > > > For example, User A creates an instance of class A which in turn
> creates
> > > > instances of classes B and C. Any update to A must also update B and
> C.
> > > > Even though objects A, B and C have been created as a result of user
> A's
> > > > actions, each object has it's own transaction object rather than a
> > > > transaction object for the client session. Is this correct?
> > > >
> > > > As I understand it, from my very limited knowledge of the subject,
> > > > Jaguar's transaction management cannot be used to handle stateful
> > > > components. Also, global variables (SQLCA in particular) are not
> session
> > > > based and cannot be used across objects, and transaction objects
> cannot
> > > > be passed as parameters to remote objects.
> > > >
> > > > It is extremely important that we manage to implement a two-tier
> > > > solution that will be easily applied to three tier. Any suggestions as
> > > > to how to do this would be greatly appreciated as I am getting more
> > > > confused by the minute!
> > > >
> > > > Sheila McCall
> > > >
> >