[Glass] Seaside transaction management

[Trussardi Dario Romano via Glass]

Ciao Johan,

	thanks.
	
> Hi Dario,
> 
> Seaside in Gemstone was written by Dale to implement a transaction for each request.
> If Seaside handles a request, this corresponds to a single transaction.
> If the commit fails, the request will be retried after an abort.
> 
> See https://gemstonesoup.wordpress.com/2007/05/07/transparent-persistence-for-seaside/ for more info.
> 
> Does this answer what you are looking for?

	My problem:

	when i submit a web seaside request sometime i do:
		
		1) Create a document to be persistence

		2) Manage a Printer device tcp/ip session to printer some tickets relative to the document

	Now the		point 1 is faster

				the point 2 is slow, the printer device are slow....

	In this situations when i do the point 1 i do:

		a) getWriteLock  on a persistence object aDocumentLock with:
			
			aDocumentLock getWriteLock
			
		where:
			getWriteLock
			
			System writeLock: self 
				ifDenied: [ self getWriteLock: 1] 
				ifChanged: [System abortTransaction].
		
				System addToCommitOrAbortReleaseLocksSet: self.

		where: 

			getWriteLock: cnt
	
			System writeLock: self 
					ifDenied:[ cnt < 1000 ifTrue: [self getWriteLock: cnt +1 ]
							  ifFalse:[ DTRApplicationEnvError signal: 'Conflitto gestionale:  Write Lock Denied' ]] 
					ifChanged:[System abortTransaction].
		
			System addToCommitOrAbortReleaseLocksSet: self.

	( i write this code some time ago. I have to check if still valid )

	This manage a conflict for create document by some web request user.

	Only one user request at time.

	But this aDocumentLock getWriteLock is seaside request transaction long.

	And because the point 2 is slow the system is blocked until the point2 

		a) is terminate with relative printer device ok seaside answer
	
		B)  or erase a device tcp/ip connection error with relative web user dialog reporter ( a seaside answer point 4 ).

	


	Then i think to commit the seaside transaction at the end of the point 1

	to permit other user to create new document.

	This is theoretical situation and i need to do some test to understand the environment behavior......



	N.B.  Any printer device define a semaphore to manage acces to the device.

		The device persistence instance define:

		1)accessSema

			"Semaphore into OODB " 
	
			^ accessSema ifNil:[ accessSema := TransientSemaphore forMutualExclusion ] 

		2) critical: mutuallyExcludedBlock 

			^ self accessSema critical: mutuallyExcludedBlock 

		3) The block 3a and the call 3b to printer the ticket 

		 	3a) aBlock:= [itemDbCasse linkModuloTicketGestionale
										newOn: dcmModel
										dettagli: flagDettagli
										onPrinter: aDevice
										forCentri: #(#all)  ].	
	
			3b) self managePrintBlock: aBlock onDevice: aDevice

		4) 	The WAComponent method:

			managePrintBlock: aBlock onDevice: aDevice

				|  flag count loopLimited rsl chiusuraForzata exception |
				flag := true.
				count := 0.
				loopLimited := aDevice loopForDeviceError.
				chiusuraForzata := false.
	
			[ flag ] whileTrue:[
				count := count+1.
				rsl := aDevice critical:[[self doBlockOnPrinter: aBlock]
									on: Error do: [:ex | exception := ex. false ]].
						
				rsl ifFalse:[ chiusuraForzata := self masterView jqDialog:
												( WADTRPrinterDialogOkErrore openOnException: exception 
																			onModel: nil
																			close: count >= loopLimited )
												title:'Errore'.
									chiusuraForzata ifNil:[ chiusuraForzata := true].
									chiusuraForzata ifTrue:[ flag := false.]]
					ifTrue:[ ^true ]].
	 				^false
						


	
		5) doBlockOnPrinter: aBlock
			" Esegue aBlock intercettando Printer error 
			( che sono tutti gli errori perchè resignalAs: PrinterTicketError) 
			Viene richiamato da critical "
	
			| tentativiStampa counterLoop  chiusuraForzata delay |
	
			tentativiStampa := 4. 	"aPrinter loopForDeviceError."
			counterLoop := 0.
			chiusuraForzata := false.
			delay:= 100.		 " milliseconds "
	
	
			aBlock on: PrinterTicketError do:[ :ex |
									counterLoop := counterLoop + 1. 
											
									counterLoop < tentativiStampa 
											ifTrue:[  (Delay forMilliseconds: delay ) wait]
											ifFalse:[ chiusuraForzata :=true].
										
									chiusuraForzata ifTrue:[ ex pass  ]
													ifFalse:[ ex retry]].
												
			^ true 

-----------------------------------------------------------

	I write this now and i'm ......
	Considerations - suggestions - ideas are welcome.
	Thanks,	
		Dario

		
> best
> Johan
> 
>> On 8 Jun 2017, at 12:38, Trussardi Dario Romano via Glass <glass at lists.gemtalksystems.com> wrote:
>> 
>> Ciao,
>> 
>> 	i have seaside application.
>> 
>> 	I need to manage a commit after create some data (  to be commit  )
>> 
>> 	but before return answer to the web request.
>> 
>> 	The 	System commit 		in the seaside  transaction answer a error.
>> 	
>> 	I read  the https://github.com/GsDevKit/gsApplicationTools/blob/master/docs/gettingStarted.md#table-of-contents
>> 
>> 	But the	 doBasicTransaction:		it's the right solutions?
>> 
>> 	If it is right the	 doBasicTransaction:   is sent to ? in the smalltalk code. 
>> 
>> 	http://downloads.gemtalksystems.com/docs/GemStone64/3.1.x/GS64-ProgGuide-3.1.pdf
>> Where i can found information about transaction into  seaside applications?
>> 	Thanks,
>> 		Dario
>> 
>> 	
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
> 
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170608/fe3244e5/attachment.html>